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An Overview of the IETF Network Management Standards 
Abstract 


This document gives an overview of the IETF network management 
standards and summarizes existing and ongoing development of IETF 
Standards Track network management protocols and data models. The 
document refers to other overview documents, where they exist and 
classifies the standards for easy orientation. The purpose of this 
document is, on the one hand, to help system developers and users to 
select appropriate standard management protocols and data models to 
address relevant management needs. On the other hand, the document 
can be used as an overview and guideline by other Standard 
Development Organizations or bodies planning to use IETF management 
technologies and data models. This document does not cover 
Operations, Administration, and Maintenance (OAM) technologies on the 
data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) 
OAM, and pseudowire as well as the corresponding management models. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6632. 
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1. Introduction 
1.1. Scope and Target Audience 


This document gives an overview of the IETF network management 
standards and summarizes existing and ongoing development of IETF 
Standards Track network management protocols and data models. The 
document refers to other overview documents where they exist and 
classifies the standards for easy orientation. 


The target audience of the document is, on the one hand, IETF working 
groups, which aim to select appropriate standard management protocols 
and data models to address their needs concerning network management. 
On the other hand, the document can be used as an overview and 
guideline by non-IETF Standards Development Organizations (SDOs) 
planning to use IETF management technologies and data models for the 
realization of management applications. The document can also be 
used to initiate a discussion between the bodies with the goal to 
gather new requirements and to detect possible gaps. Finally, this 
document is directed to all interested parties that seek to get an 
overview of the current set of the IETF network management protocols 
such as network administrators or newcomers to the IETF. 


Section 2 gives an overview of the IETF core network management 
standards with a special focus on Simple Network Management Protocol 
(SNMP), syslog, IP Flow Information eXport / Packet SAMPling (IPFIX/ 
PSAMP), and Network Configuration (NETCONF). Section 3 discusses 
IETF management protocols and mechanisms with a specific focus, e.g., 
IP address management or IP performance management. Section 4 
discusses IETF data models, such as MIB modules, IPFIX Information 
Elements, Syslog Structured Data Elements, and YANG modules designed 
to address a specific set of management issues and provides two 
complementary overviews for the network management data models 
standardized within the IETF. Section 4.1 focuses on a broader view 
of models classified into categories such as generic and 
infrastructure data models as well as data models matched to 
different layers. Whereas Section 4.2 structures the data models 
following the management application view and maps them to the 
network management tasks fault, configuration, accounting, 
performance, and security management. 


Appendix A guides the reader for the high-level selection of 
management standards. For this, the section classifies the protocols 
according to high-level criteria, such as push versus pull 
mechanisms, passive versus active monitoring, as well as categorizes 
the protocols concerning the network management task they address and 
their data model extensibility. If the reader is interested only in 
a subset of the IETF network management protocols and data models 
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described in this document, Appendix A can be used as a dispatcher to 
the corresponding chapter. Appendix B gives an overview of the new 
work on Energy Management in the IETF. 


This document mainly refers to Proposed, Draft, or Internet Standard 
documents from the IETF (see [RFCSEARCH]). Whenever valuable, Best 
Current Practice (BCP) documents are referenced. In exceptional 
cases, and if the document provides substantial guideline for 
standard usage or fills an essential gap, Experimental and 
Informational RFCs are noticed and ongoing work is mentioned. 


Information on active and concluded IETF working groups (e.g., their 
charters, published or currently active documents, and mail archives) 
can be found at [IETF-WGS]). 


Note that this document does not cover OAM technologies on the data- 
path including MPLS forwarding plane and control plane protocols 
(e.g., OAM of tunnels, MPLS-TP OAM, and pseudowire) as well as the 
corresponding management models and MIB modules. For a list of 
related work, see Section 1.2. 


1.2. Related Work 


"Internet Protocols for the Smart Grid" [RFC6272] gives an overview 
and guidance on the key protocols of the Internet Protocol Suite. In 
analogy to [RFC6272], this document gives an overview of the IETF 
network management standards and their usage scenarios. 


"Overview of the 2002 IAB Network Management Workshop" [RFC3535] 
documented strengths and weaknesses of some IETF management 
protocols. In choosing existing protocol solutions to meet the 
management requirements, it is recommended that these strengths and 
weaknesses be considered, even though some of the recommendations 
from the 2002 IAB workshop have become outdated, some have been 
standardized, and some are being worked on within the IETF. 


"Guidelines for Considering Operations and Management of New 
Protocols and Extensions" [RFC5706] recommends working groups 
consider operations and management needs and then select appropriate 
management protocols and data models. This document can be used to 
ease surveying the IETF Standards Track network management protocols 
and management data models. 


"Multiprotocol Label Switching (MPLS) Management Overview" [RFC4221] 
describes the management architecture for MPLS and indicates the 
interrelationships between the different MIB modules used for MPLS 
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network management, where "Operations, Administration, and 
Maintenance Framework for MPLS-Based Transport Networks" [RFC6371] 
describes the OAM Framework for MPLS-based Transport Networks. 


"An Overview of Operations, Administration, and Maintenance (OAM) 
Mechanisms" [OAM-OVERVIEW] gives an overview of the OAM toolset for 
detecting and reporting connection failures or measuring connection 
performance parameters. 


"An Overview of the OAM Tool Set for MPLS-based Transport Networks" 
[OAM-ANALYSIS] provides an overview of the OAM toolset for MPLS-based 
Transport Networks including a brief summary of MPLS-TP OAM 
requirements and functions and of generic mechanisms created in the 
MPLS data plane to allow the OAM packets run in-band and share their 
fate with data packets. The protocol definitions for each MPLS-TP 
OAM tool are listed in separate documents, which are referenced. 


"MPLS-TP MIB-based Management Overview" [MPLSTP-MIB] describes the 
MIB-based architecture for MPLS-TP, and indicates the 
interrelationships between different existing MIB modules that can be 
leveraged for MPLS-TP network management and identifies areas where 
additional MIB modules are required. 


Note that so far, the IETF has not developed specific technologies 
for the management of sensor networks. IP-based sensors or 
constrained devices in such an environment, i.e., with very limited 
memory and CPU resources, Can use, e.g., application-layer protocols 
to do simple resource management and monitoring. 


1.3. Terminology 


This document does not describe standard requirements. Therefore, 
key words from RFC 2119 [RFC2119] are not used in the document. 


o 3GPP: 3rd Generation Partnership Project, a collaboration between 
groups of telecommunications associations, to prepare the third- 
generation (3G) mobile phone system specification. 


o Agent: A software module that performs the network management 
functions requested by network management stations. An agent may 
be implemented in any network element that is to be managed, such 
as a host, bridge, or router. The “management server’ in NETCONF 
terminology. 


o BCP: An IETF Best Current Practice document. 


o CLI: Command Line Interface. A management interface that system 
administrators can use to interact with networking equipment. 
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o Data model: A mapping of the contents of an information model into 
a form that is specific to a particular type of datastore or 
repository (see [RFC3444]). 


o Event: An occurrence of something in the "real world". Events can 
be indicated to managers through an event message or notification. 


o IAB: Internet Architecture Board 


o IANA: Internet Assigned Numbers Authority, an organization that 
oversees global IP address allocation, autonomous system number 
allocation, media types, and other IP-related code point 
allocations. 


o Information model: An abstraction and representation of entities 
in a managed environment, their properties, attributes, 
operations, and the way they relate to each other, independent of 
any specific repository, protocol, or platform (see [RFC3444]). 


o ITU-T: International Telecommunication Union - Telecommunication 
Standardization Sector 


o Managed object: A management abstraction of a resource; a piece of 
management information in a MIB module. In the context of SNMP, a 
structured set of data variables that represent some resource to 
be managed or other aspect of a managed device. 


o Manager: An entity that acts in a manager role, either a user or 
an application. The counterpart to an agent. A 'management 
client’ in NETCONF terminology. 


o Management Information Base (MIB): An information repository with 
a collection of related objects that represent the resources to be 
managed. 


o MIB module: MIB modules usually contain object definitions, may 
contain definitions of event notifications, and sometimes include 
compliance statements in terms of appropriate object and event 
notification groups. A MIB that is provided by a management agent 
is typically composed of multiple instantiated MIB modules. 


o Modeling language: A modeling language is any artificial language 
that can be used to express information or knowledge or systems in 
a structure that is defined by a consistent set of rules. 
Examples are Structure of Management Information Version 2 (SMIv2) 
[STD58], XML Schema Definition (XSD) [XSD-1], and YANG [RFC6020]. 
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Notification: An unsolicited message sent by an agent to a 
management station to notify it of an unusual event. 


OAM: Operations, Administration, and Maintenance 


PDU: Protocol Data Unit, a unit of data, which is specified in a 
protocol of a given layer consisting protocol-control information 
and possibly layer-specific data. 


Principal: An application, an individual, or a set of individuals 
acting in a particular role, on whose behalf access to a service 
or MIB is allowed. 


RELAX NG: REgular LAnguage for XML Next Generation, a schema 
language for XML [RELAX-NG]. 


SDO: Standards Development Organization 


SMI: Structure of Managed Information, the notation and grammar 
for the managed information definition used to define MIB modules 
[STD58]. 


STDnn: An Internet Standard published at IETF, also referred as 
Standard, e.g., [STD62]. 


URI: Uniform Resource Identifier, a string of characters used to 
identify a name or a resource on the Internet [STD66]. Can be 
classified as locators (URLs), as names (URNs), or as both. 


XPATH: XML Path Language, a query language for selecting nodes 
from an XML document [XPATH]. 


Core Network Management Protocols 


Simple Network Management Protocol (SNMP) 


Architectural Principles of SNMP 


The SNMPv3 Framework [RFC3410], builds upon both the original SNMPvl 
and SNMPv2 Frameworks. The basic structure and components for the 
SNMP Framework did not change between its versions and comprises the 
following components: 


o 


managed nodes, each with an SNMP entity providing remote access to 
management instrumentation (the agent), 


at least one SNMP entity with management applications (the 
manager), and 
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o a management protocol used to convey management information 
between the SNMP entities and management information. 


During its evolution, the fundamental architecture of the SNMP 
Management Framework remained consistent based on a modular 
architecture, which consists of: 


o a generic protocol definition independent of the data it is 
carrying, 


o a protocol-independent data definition language, 

o an information repository containing a data set of management 
information definitions (the Management Information Base, or MIB), 
and 


o security and administration. 


As such, the following standards build up the basis of the current 
SNMP Management Framework: 


o the SNMPv3 protocol [STD62], 
o the modeling language SMIv2 [STD58], and 
o the MIB modules for different management issues. 


The SNMPv3 Framework extends the architectural principles of SNMPv1 
and SNMPv2 by: 


o building on these three basic architectural components, in some 
cases, incorporating them from the SNMPv2 Framework by reference, 
and 


o by using the same layering principles in the definition of new 
capabilities in the security and administration portion of the 
architecture. 


-2. SNMP and Its Versions 


SNMP is based on three conceptual entities: Manager, Agent, and the 
Management Information Base (MIB). In any configuration, at least 
one manager node runs SNMP management software. Typically, network 
devices, such as bridges, routers, and servers, are equipped with an 
agent. The agent is responsible for providing access to a local MIB 
of objects that reflects the resources and activity at its node. 
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Following the manager-agent paradigm, an agent can generate 
notifications and send them as unsolicited messages to the management 
application. 


SNMPv2 enhances this basic functionality with an Inform PDU, a bulk 
transfer capability and other functional extensions like an 
administrative model for access control, security extensions, and 
Manager-to-Manager communication. SNMPv2 entities can have a dual 
role as manager and agent. However, neither SNMPvl nor SNMPv2 offers 
sufficient security features. To address the security deficiencies 
of SNMPv1/v2, SNMPv3 [STD62] has been issued. 


"Coexistence between Version 1, Version 2, and Version 3 of the 
Internet-standard Network Management Framework" [BCP074] gives an 
overview of the relevant Standard documents on the three SNMP 
versions. The BCP document furthermore describes how to convert MIB 
modules from SMIvl to SMIv2 format and how to translate notification 
parameters. It also describes the mapping between the message 
processing and security models. 


SNMP utilizes the MIB, a virtual information store of modules of 
managed objects. Generally, standard MIB modules support common 
functionality in a device. Operators often define additional MIB 
modules for their enterprise or use the Command Line Interface (CLI) 
to configure non-standard data in managed devices and their 
interfaces. 


SNMPv2 Trap and Inform PDUs can alert an operator or an application 
when some aspects of a protocol fail or encounter an error condition, 
and the contents of a notification can be used to guide subsequent 
SNMP polling to gather additional information about an event. 


SNMP is widely used for the monitoring of fault and performance data 
and with its stateless nature, SNMP also works well for status 
polling and determining the operational state of specific 
functionality. The widespread use of counters in standard MIB 
modules permits the interoperable comparison of statistics across 
devices from different vendors. Counters have been especially useful 
in monitoring bytes and packets going in and out over various 
protocol interfaces. SNMP is often used to poll a basic parameter of 
a device (e.g., sysUpTime, which reports the time since the last re- 
initialization of the network management portion of the device) to 
check for operational liveliness and to detect discontinuities in 
counters. Some operators also use SNMP for configuration management 
in their environment (e.g., for systems based on Data Over Cable 
Service Interface Specification (DOCSIS) such as cable modems) . 


Ersue & Claise Informational [Page 10] 


RFC 6632 IETF Management Standards June 2012 


SNMPv1 [RFC1157] has been declared Historic and its use is not 
recommended due to its lack of security features. "Introduction to 
Community-based SNMPv2" [RFC1901] is an Experimental RFC, which has 
been declared Historic, and its use is not recommended due to its 
lack of security features. 


Use of SNMPv3 [STD62] is recommended due to its security features, 
including support for authentication, encryption, message timeliness 
and integrity checking, and fine-grained data access controls. An 
overview of the SNMPv3 document set is in [RFC3410]. 


Standards exist to use SNMP over diverse transport and link-layer 
protocols, including Transmission Control Protocol (TCP) [STDO7], 
User Datagram Protocol (UDP) [STD06], Ethernet [RFC4789], and others 
(see Section 2.1.5.1). 


2.1.3. Structure of Managed Information (SMI) 


SNMP MIB modules are defined with the notation and grammar specified 
as the Structure of Managed Information (SMI). The SMI uses an 
adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680]. 


The SMI is divided into three parts: module definitions, object 
definitions, and notification definitions. 


o Module definitions are used when describing information modules. 
An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 
semantics of an information module. 


o Object definitions are used when describing managed objects. An 
ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 
and semantics of a managed object. 


o Notification definitions are used when describing unsolicited 
transmissions of management information. An ASN.1 macro, 
NOTIFICATION-TYPE, is used to concisely convey the syntax and 
semantics of a notification. 


SMIv1 is specified in "Structure and Identification of Management 
Information for TCP/IP-based Internets" [RFC1155] and "Concise MIB 
Definitions" [RFC1212], both part of [STD16]. [RFC1215] specifies 
conventions for defining SNMP traps. Note that SMIvl is outdated and 
its use is not recommended. 


SMIv2 is the new notation for managed information definitions and 
should be used to define MIB modules. SMIv2 is specified in the 
following RFCs. With the exception of BCP 74, they are all part of 
[STD58]: 
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o [RFC2578] defines Version 2 of the Structure of Management 
Information (SMIv2), 


o [RFC2579] defines the textual conventions macro for defining new 
types and it provides a core set of generally useful textual 
convention definitions, 


o [RFC2580] defines conformance statements and requirements for 
defining agent and manager capabilities, and 


o [BCP074] defines the mapping rules for and the conversion of MIB 
modules between SMIv1 and SMIv2 formats. 


2.1.4. SNMP Security and Access Control Models 
2.1.4.1. Security Requirements on the SNMP Management Framework 


Several of the classical threats to network protocols are applicable 
to management problem space and therefore are applicable to any 
security model used in an SNMP Management Framework. This section 
lists primary and secondary threats, and threats that are of lesser 
importance (see [RFC3411] for the detailed description of the 
security threats). 


The primary threats against which SNMP Security Models can provide 
protection are, "modification of information" by an unauthorized 
entity, and "masquerade", i.e., the danger that management operations 
not authorized for some principal may be attempted by assuming the 
identity of another principal. 


Secondary threats against which SNMP Security Models can provide 
protection are "message stream modification", e.g., reordering, 
delay, or replay of messages, and "disclosure", i.e., the danger of 
eavesdropping on the exchanges between SNMP engines. 


There are two threats against which the SNMP Security Model does not 
protect, since they are deemed to be of lesser importance in this 
context: Denial of Service and Traffic Analysis (see [RFC3411]). 


2.1.4.2. User-Based Security Model (USM) 


SNMPv3 [STD62] introduced the User-based Security Model (USM). USM 
is specified in [RFC3414] and provides authentication and privacy 
services for SNMP. Specifically, USM is designed to secure against 
the primary and secondary threats discussed in Section 2.1.4.1. USM 
does not secure against Denial of Service and attacks based on 
Traffic Analysis. 
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The USM supports following security services: 


o Data integrity is the provision of the property that data has not 
been altered or destroyed in an unauthorized manner, nor have data 
sequences been altered to an extent greater than can occur non- 
maliciously. 


o Data origin authentication is the provision of the property that 
the claimed identity of the user on whose behalf received data was 
originated is supported. 


o Data confidentiality is the provision of the property that 
information is not made available or disclosed to unauthorized 
individuals, entities, or processes. 


o Message timeliness and limited replay protection is the provision 
of the property that a message whose generation time is outside of 
a specified time window is not accepted. 


See [RFC3414] for a detailed description of SNMPv3 USM. 
2.1.4.3. View-Based Access Control Model (VACM) 


SNMPv3 [STD62] introduced the View-based Access Control (VACM) 
facility. The VACM is defined in [RFC3415] and enables the 
configuration of agents to provide different levels of access to the 
agent’s MIB. An agent entity can restrict access to a certain 
portion of its MIB, e.g., restrict some principals to view only 
performance-related statistics or disallow other principals to read 
those performance-related statistics. An agent entity can also 
restrict the access to monitoring (read-only) as opposed to 
monitoring and configuration (read-write) of a certain portion of its 
MIB, e.g., allowing only a single designated principal to update 
configuration parameters. 


VACM defines five elements that make up the Access Control Model: 
groups, security level, contexts, MIB views, and access policy. 
Access to a MIB module is controlled by means of a MIB view. 


See [RFC3415] for a detailed description of SNMPv3 VACM. 

2.1.5. SNMP Transport Subsystem and Transport Models 
The User-based Security Model (USM) was designed to be independent of 
other existing security infrastructures to ensure it could function 


when third-party authentication services were not available. Asa 
result, USM utilizes a separate user and key-management 
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infrastructure. Operators have reported that the deployment of a 
separate user and key-management infrastructure in order to use 
SNMPv3 is costly and hinders the deployment of SNMPv3. 


SNMP Transport Subsystem [RFC5590] extends the original SNMP 
architecture and Transport Model and enables the use of transport 
protocols to provide message security unifying the administrative 
security management for SNMP and other management interfaces. 


Transport Models are tied into the SNMP Framework through the 
Transport Subsystem. The Transport Security Model [RFC5591] has been 
designed to work on top of lower-layer, secure Transport Models. 


The SNMP Transport Model defines an alternative to existing standard 
transport mappings described in [RFC3417], e.g., for SNMP over UDP, 
in [RFC4789] for SNMP over IEEE 802 networks, and in the Experimental 
RFC [RFC3430] defining SNMP over TCP. 


2.1.5.1. SNMP Transport Security Model 
The SNMP Transport Security Model [RFC5591] is an alternative to the 


existing SNMPv1 and SNMPv2 Community-based Security Models [BCP074], 
and the User-based Security Model [RFC3414], part of [STD62]. 


The Transport Security Model utilizes one or more lower-layer 
security mechanisms to provide message-oriented security services. 
These include authentication of the sender, encryption, timeliness 
checking, and data integrity checking. 


A secure Transport Model sets up an authenticated and possibly 
encrypted session between the Transport Models of two SNMP engines. 
After a transport-layer session is established, SNMP messages can be 
sent through this session from one SNMP engine to the other. The new 
Transport Model supports the sending of multiple SNMP messages 
through the same session to amortize the costs of establishing a 
security association. 


The Secure Shell (SSH) Transport Model [RFC5592] and the Transport 
Layer Security (TLS) Transport Model [RFC6353] are current examples 
of Transport Security Models. 


The SSH Transport Model makes use of the commonly deployed SSH 
security and key-management infrastructure. Furthermore, [RFC5592] 
defines MIB objects for monitoring and managing the SSH Transport 
Model for SNMP. 
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The Transport Layer Security (TLS) Transport Model [RFC6353] uses 
either the TLS protocol [RFC5246] or the Datagram Transport Layer 
Security (DTLS) protocol [RFC6347]. The TLS and DTLS protocols 
provide authentication and privacy services for SNMP applications. 
The TLS Transport Model supports the sending of SNMP messages over 
TLS and TCP and over DTLS and UDP. Furthermore, [RFC6353] defines 
MIB objects for managing the TLS Transport Model for SNMP. 


[RFC5608] describes the use of a Remote Authentication Dial-In User 
Service (RADIUS) service by SNMP secure Transport Models for 
authentication of users and authorization of services. Access 
control authorization, i.e., how RADIUS attributes and messages are 
applied to the specific application area of SNMP Access Control 
Models, and VACM in particular has been specified in [RFC6065]. 


2.2. Syslog Protocol 


Syslog is a mechanism for distribution of logging information 
initially used on Unix systems (see [RFC3164] for BSD syslog). The 
IETF Syslog Protocol [RFC5424] introduces a layered architecture 
allowing the use of any number of transport protocols, including 
reliable and secure transports, for transmission of syslog messages. 


The Syslog protocol enables a machine to send system log messages 
across networks to event message collectors. The protocol is simply 
designed to transport and distribute these event messages. By 
default, no acknowledgements of the receipt are made, except the 
reliable delivery extensions specified in [RFC3195] are used. The 
Syslog protocol and process does not require a stringent coordination 
between the transport sender and the receiver. Indeed, the 
transmission of syslog messages may be started on a device without a 
receiver being configured, or even actually physically present. 
Conversely, many devices will most likely be able to receive messages 
without explicit configuration or definitions. 


BSD syslog had little uniformity for the message format and the 
content of syslog messages. The body of a BSD syslog message has 
traditionally been unstructured text. This content is human 
friendly, but difficult to parse for applications. With the Syslog 
Protocol [RFC5424], the IETF has standardized a new message header 
format, including timestamp, hostname, application, and message ID, 
to improve filtering, interoperability, and correlation between 
compliant implementations. 


The Syslog protocol [RFC5424] also introduces a mechanism for 
defining Structured Data Elements (SDEs). The SDEs allow vendors to 
define their own structured data elements to supplement standardized 
elements. [RFC5675] defines a mapping from SNMP notifications to 
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syslog messages. [RFC5676] defines an SNMP MIB module to represent 
syslog messages for the purpose of sending those syslog messages as 
notifications to SNMP notification receivers. [RFC5674] defines the 


way alarms are sent in syslog, which includes the mapping of ITU- 
perceived severities onto syslog message fields and a number of 
alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF 
Alarm MIB [RFC3877]. 


"Signed Syslog Messages" [RFC5848] defines a mechanism to add origin 
authentication, message integrity, replay resistance, message 
sequencing, and detection of missing messages to the transmitted 
syslog messages to be used in conjunction with the Syslog protocol. 


The Syslog protocol’s layered architecture provides support for a 
number of transport mappings. For interoperability purposes and 
especially in managed networks, where the network path has been 
explicitly provisioned for UDP syslog traffic, the Syslog protocol 
can be used over UDP [RFC5426]. However, to support congestion 
control and reliability, [RFC5426] strongly recommends the use of the 
TLS transport. 


Furthermore, the IETF defined the TLS Transport Mapping for syslog in 
[RFC5425], which provides a secure connection for the transport of 
syslog messages. [RFC5425] describes the security threats to syslog 
and how TLS can be used to counter such threats. [RFC6012] defines 
the Datagram Transport Layer Security (DTLS) Transport Mapping for 
syslog, which can be used if a connectionless transport is desired. 


For information on MIB modules related to syslog, see Section 4.2.1. 


2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP) 
Protocols 


"Specification of the IP Flow Information Export (IPFIX) Protocol for 
the Exchange of IP Traffic Flow Information" (the IPFIX Protocol) 
[RFC5101] defines a push-based data export mechanism for transferring 
IP flow information in a compact binary format from an Exporter to a 
Collector. 


"Architecture for IP Flow Information Export" (the IPFIX 
Architecture) [RFC5470] defines the components involved in IP flow 
measurement and reporting of information on IP flows, particularly, a 
Metering Process generating Flow Records, an Exporting Process that 
sends metered flow information using the IPFIX protocol, anda 
Collecting Process that receives flow information as IPFIX Data 
Records. 
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After listing the IPFIX requirements in [RFC3917], NetFlow Version 9 
[RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX 
architecture. 


IPFIX can run over different transport protocols. The IPFIX Protocol 
[RFC5101] specifies Stream Control Transmission Protocol (SCTP) 
[RFC4960] as the mandatory transport protocol to implement. Optional 
alternatives are TCP [STDO7] and UDP [STDO6]. 


SCTP is used with its Partial Reliability extension (PR-SCTP) 
specified in [RFC3758]. [RFC6526] specifies an extension to 
[RFC5101], when using the PR-SCTP [RFC3758]. The extension offers 
several advantages over IPFIX export, e.g., the ability to calculate 
Data Record losses for PR-SCTP, immediate reuse of Template IDs 
within an SCTP stream, reduced likelihood of Data Record loss, and 
reduced demands on the Collecting Process. 


IPFIX transmits IP flow information in Data Records containing IPFIX 
Information Elements (IEs) defined by the IPFIX Information Model 
[RFC5102]. IPFIX IEs are quantities with unit and semantics defined 
by the Information Model. When transmitted over the IPFIX protocol, 
only their values need to be carried in Data Records. This compact 
encoding allows efficient transport of large numbers of measured flow 
values. Remaining redundancy in Data Records can be further reduced 
by the methods described in [RFC5473] (for further discussion on 
IPFIX IEs, see Section 4). 


The IPFIX Information Model is extensible. New IEs can be registered 
at IANA (see "IPFIX Information Elements" in [IANA-PROT]). IPFIX 
also supports the use of proprietary, i.e., enterprise-specific IEs. 


The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of 
transferring information on individual packets. [RFC5475] specifies 
a set of sampling and filtering techniques for IP packet selection, 
based on the PSAMP Framework [RFC5474]. The PSAMP Information Model 
[RFC5477] provides a set of basic IEs for reporting packet 
information with the IPFIX/PSAMP protocol. 


The IPFIX model of an IP traffic flow is unidirectional. [RFC5103] 
adds means of reporting bidirectional flows to IPFIX, for example, 
both directions of packet flows of a TCP connection. 


When enterprise-specific IEs are transmitted with IPFIX, a Collector 
receiving Data Records may not know the type of received data and 
cannot choose the right format for storing the contained information. 
[RFC5610] provides a means of exporting extended type information for 
enterprise-specific Information Elements from an Exporter to a 
Collector. 


Ersue & Claise Informational [Page 17] 


RFC 6632 IETF Management Standards June 2012 


Collectors may store received flow information in files. The IPFIX 
file format [RFC5655] can be used for storing IP flow information in 
a way that facilitates exchange of traffic flow information between 
different systems and applications. 


In terms of IPFIX and PSAMP configurations, the Metering and 
Exporting Processes are configured out of band. As the IPFIX 
protocol is a push mechanism only, IPFIX cannot configure the 
Exporter. The actual configuration of selection processes, caches, 
Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- 
compliant monitoring devices is executed using the NETCONF protocol 
[RFC6241] (see Section 2.4.1). The "Configuration Data Model for 
IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL] 
has been specified using Unified Modeling Language (UML) class 
diagrams. The data model is formally defined using the YANG modeling 
language [RFC6020] (see Section 2.4.2). 


At the time of this writing, a framework for IPFIX flow mediation is 
in preparation, which addresses the need for mediation of flow 
information in IPFIX applications in large operator networks, e.g., 
for aggregating huge amounts of flow data and for anonymization of 
flow information (see the problem statement in [RFC5982]). 


The IPFIX Mediation Framework [RFC6183] defines the intermediate 
device between Exporters and Collectors, which provides an IPFIX 
mediation by receiving a record stream from, e.g., a Collecting 
Process, hosting one or more Intermediate Processes to transform this 
stream, and exporting the transformed record stream into IPFIX 
messages via an Exporting Process. 


Examples for mediation functions are flow aggregation, flow 
selection, and anonymization of traffic information (see [RFC6235]). 


Privacy, integrity, and authentication of the Exporter and Collector 
are important security requirements for IPFIX [RFC3917]. 
Confidentiality, integrity, and authenticity of IPFIX data 
transferred from an Exporting Process to a Collecting Process must be 
ensured. The IPFIX and PSAMP protocols do not define any new 
security mechanisms and rely on the security mechanism of the 
underlying transport protocol, such as TLS [RFC5246] and DTLS 
[RFC6347]. 


The primary goal of IPFIX is the reporting of the flow accounting for 
flexible flow definitions and usage-based accounting. As described 
in the IPFIX Applicability Statement [RFC5472], there are also other 
applications such as traffic profiling, traffic engineering, 
intrusion detection, and QoS monitoring, that require flow-based 
traffic measurements and can be realized using IPFIX. Furthermore, 
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the IPFIX Applicability Statement explains the relation of IPFIX to 
other framework and protocols such as PSAMP, RMON (Remote Network 
Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics, 
Section 3.4)). Similar flow information could be also used for 
security monitoring. The addition of Performance Metrics in the 
IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to 
performance management. 


Note that even if the initial IPFIX focus has been around IP flow 
information exchange, non-IP-related IEs are now specified in the 
IPFIX IANA registration (e.g., MAC (Media Access Control) address, 
MPLS (Multiprotocol Label Switching) labels, etc.). At the time of 
this writing, there are requests to widen the focus of IPFIX and to 
export non-IP related IEs (such as SIP monitoring IEs). 


The IPFIX structured data [RFC6313] is an extension to the IPFIX 
protocol, which supports hierarchical structured data and lists 
(sequences) of Information Elements in Data Records. This extension 
allows the definition of complex data structures such as variable- 
length lists and specification of hierarchical containment 
relationships between templates. Furthermore, the extension provides 
the semantics to express the relationship among multiple list 
elements in a structured Data Record. 


For information on data models related to the management of the IPFIX 
and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For information 
on IPFIX/PSAMP IEs, see Section 4.2.3. 

2.4. Network Configuration 


2.4.1. Network Configuration Protocol (NETCONF) 


The IAB workshop on Network Management [RFC3535] determined advanced 
requirements for configuration management: 


o robustness: Minimizing disruptions and maximizing stability, 
o a task-oriented view, 

o extensibility for new operations, 

o standardized error handling, 


o clear distinction between configuration data and operational 
state, 


o distribution of configurations to devices under transactional 
constraints, 
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o single- and multi-system transactions and scalability in the 
number of transactions and managed devices, 


o operations on selected subsets of management data, 


o dumping and reloading a device configuration in a textual format 
in a standard manner across multiple vendors and device types, 


o a human interface and a programmatic interface, 

o a data modeling language with a human-friendly syntax, 

o easy conflict detection and configuration validation, and 

o secure transport, authentication, and robust access control. 


The NETCONF protocol [RFC6241] provides mechanisms to install, 
manipulate, and delete the configuration of network devices and aims 
to address the configuration management requirements pointed out in 
the IAB workshop. It uses an XML-based data encoding for the 
configuration data as well as the protocol messages. The NETCONF 
protocol operations are realized on top of a simple and reliable 
Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that 
it allows the functionality of the management protocol to closely 
mirror the native command-line interface of the device. 


The NETCONF working group developed the NETCONF Event Notifications 
Mechanism as an optional capability, which provides an asynchronous 
message notification delivery service for NETCONF [RFC5277]. The 
NETCONF notification mechanism enables using general purpose 
notification streams, where the originator of the notification stream 
can be any managed device (e.g., SNMP notifications). 


The NETCONF Partial Locking specification introduces fine-grained 
locking of the configuration datastore to enhance NETCONF for fine- 
grained transactions on parts of the datastore [RFC5717]. 


The NETCONF working group also defined the necessary data model to 
monitor the NETCONF protocol [RFC6022], by using the modeling 
language YANG [RFC6020] (see Section 2.4.2). The monitoring data 
model includes information about NETCONF datastores, sessions, locks, 
and statistics, which facilitate the management of a NETCONF server. 


NETCONF connections are required to provide authentication, data 
integrity, confidentiality, and replay protection. NETCONF depends 
on the underlying transport protocol for this capability. For 
example, connections can be encrypted in TLS or SSH, depending on the 
underlying protocol. 
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The NETCONF working group defined the SSH transport protocol as the 
mandatory transport binding [RFC6242]. Other optional transport 
bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol 
(BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP) 
over HTTP over TLS [RFC4743]. 


The NETCONF Access Control Model (NACM) [RFC6536] provides standard 
mechanisms to restrict protocol access to particular users with a 
pre-configured subset of operations and content. 


2.4.2. YANG - NETCONF Data Modeling Language 


Following the guidelines of the IAB management workshop [RFC3535], 
the NETMOD working group developed a data modeling language defining 
the semantics of operational and configuration data, notifications, 
and operations [RFC6020]. The new data modeling language, called 
YANG, maps directly to XML-encoded content (on the wire) and will 
serve as the normative description of NETCONF data models. 


YANG has the following properties addressing specific requirements on 
a modeling language for configuration management: 


o YANG provides the means to define hierarchical data models. It 
supports reusable data types and groupings, i.e., a set of schema 
nodes that can be reused across module boundaries. 


o YANG supports the distinction between configuration and state 
data. In addition, it provides support for modeling event 
notifications and the specification of operations that extend the 
base NETCONF operations. 


o YANG allows the expression of constraints on data models by means 
of type restrictions and XML Path Language (XPATH) 1.0 [XPATH] 
expressions. XPATH expressions can also be used to make certain 
portions of a data model conditional. 


o YANG supports the integration of standard- and vendor-defined data 
models. YANG’s augmentation mechanism allows the seamless 
augmentation of standard data models with proprietary extensions. 


o YANG data models can be partitioned into collections of features, 
allowing low-end devices only to implement the core features of a 
data model while high-end devices may choose to support all 
features. The supported features are announced via the NETCONF 
capability exchange to management applications. 
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o The syntax of the YANG language is compact and optimized for human 
readers. An associated XML-based syntax called the YANG 
Independent Notation (YIN) [RFC6020] is available to allow the 
processing of YANG data models with XML-based tools. The mapping 
rules for the translation of YANG data models into Document Schema 
Definition Languages (DSDL), of which RELAX NG is a major 
component, are defined in [RFC6110]. 


o Devices implementing standard data models can document deviations 
from the data model in separate YANG modules. Applications 
capable of discovering deviations can make allowances that would 
otherwise not be possible. 


A collection of common data types for IETF-related standards is 
provided in [RFC6021]. This standard data type library has been 
derived to a large extend from common SMIv2 data types, generalizing 
them to a less-constrained NETCONF Framework. 


The document "An Architecture for Network Management using NETCONF 
and YANG" describes how NETCONF and YANG can be used to build network 
management applications that meet the needs of network operators 
[RFC6244]. 


The Experimental RFC [RFC6095] specifies extensions for YANG, 
introducing language abstractions such as class inheritance and 
recursive data structures. 


[RFC6087] gives guidelines for the use of YANG within the IETF and 
other standardization organizations. 


Work is underway to standardize a translation of SMIv2 data models 
into YANG data models preserving investments into SNMP MIB modules, 
which are widely available for monitoring purposes [SMI-YANG]. 


Several independent and open source implementations of the YANG data 
modeling language and associated tools are available. 


While YANG is a relatively recent data modeling language, some data 
models have already been produced. The specification of the base 
NETCONF protocol operations has been revised and uses YANG as the 
normative modeling language to specify its operations [RFC6241]. The 
IPFIX working group prepared the normative model for configuring and 
monitoring IPFIX- and PSAMP-compliant monitoring devices using the 
YANG modeling language [CONF-MODEL]. 
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At the time of this writing, the NETMOD working group is developing 
core system and interface data models. Following the example of the 
IPFIX configuration model, IETF working groups will prepare models 
for their specific needs. 


For information on data models developed using the YANG modeling 
language, see Sections 4.2.1 and 4.2.2. 


3. Network Management Protocols and Mechanisms with Specific Focus 


This section reviews additional protocols the IETF offers for 
management and discusses for which applications they were designed 
and/or have already been successfully deployed. These are protocols 
that have mostly reached Proposed Standard status or higher within 
the IETF. 


3.1. IP Address Management 
3.1.1. Dynamic Host Configuration Protocol (DHCP) 


Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a 
framework for passing configuration information to hosts on a TCP/IP 
network and, as such, enables autoconfiguration in IP networks. In 
addition to IP address management, DHCP can also provide other 
configuration information, such as default routers, the IP addresses 
of recursive DNS servers, and the IP addresses of NTP servers. As 
described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address 
Allocation and Assignment as well as for Service Discovery. 


There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and 
one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension 
to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently 
defined to accommodate new functions required by IPv6 such as 
assignment of multiple addresses to an interface and to address 
limitations in the design of DHCPv4 resulting from its origins in 
BOOTP. While both versions bear the same name and perform the same 
functionality, the details of DHCPv4 and DHCPv6 are sufficiently 
different that they can be considered separate protocols. 


In addition to the assignment of IP addresses and other configuration 
information, DHCP options like the Relay Agent Information option 
(DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] 
are widely used by ISPs. 


DHCPv6 includes Prefix Delegation [RFC3633], which is used to 
provision a router with an IPv6 prefix for use in the subnetwork 
supported by the router. 
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The following are examples of DHCP options that provide configuration 
information or access to specific servers. A complete list of DHCP 
options is available at [IANA-PROT]. 


o "DNS Configuration options for Dynamic Host Configuration Protocol 
for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing 
a list of available DNS recursive name servers and a domain search 
list to a client. 


o "DHCP Options for Service Location Protocol" [RFC2610] describes 
DHCPv4 options and methods through which entities using the 
Service Location Protocol can find out the address of Directory 
Agents in order to transact messages and how the assignment of 
scope for configuration of Service Location Protocol (SLP) User 
and Service Agents can be achieved. 


o "Dynamic Host Configuration Protocol (DHCPv6) Options for Session 
Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6 
options that allow SIP clients to locate a local SIP server that 
is to be used for all outbound SIP requests, a so-called "outbound 
proxy server". 


o "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast 
and Multicast Control Servers" [RFC4280] defines DHCPv6 options to 
discover the Broadcast and Multicast Service (BCMCS) controller in 
an IP network. 


Built directly on UDP and IP, DHCP itself has no security provisions. 
There are two different classes of potential security issues related 
to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. 

The recommended solutions to these risks generally involve providing 
security at lower layers, e.g., careful control over physical access 
to the network, security techniques implemented at Layer 2 but also 
IPsec at Layer 3 can be used to provide authentication. 


3.1.2. Ad Hoc Network Autoconfiguration 


Ad hoc nodes need to configure their network interfaces with locally 
unique addresses as well as globally routable IPv6 addresses, in 
order to communicate with devices on the Internet. The IETF AUTOCONF 
working group developed [RFC5889], which describes the addressing 
model for ad hoc networks and how nodes in these networks configure 
their addresses. 


The ad hoc nodes under consideration are expected to be able to 
support multi-hop communication by running MANET (Mobile Ad Hoc 
Network) routing protocols as developed by the IETF MANET working 
group. 


Ersue & Claise Informational [Page 24] 


RFC 6632 IETF Management Standards June 2012 


From the IP layer perspective, an ad hoc network presents itself as a 
Layer 3 multi-hop network formed over a collection of links. The 
addressing model aims to avoid problems for parts of the system that 
are ad hoc unaware, such as standard applications running on an ad 
hoc node or regular Internet nodes attached to the ad hoc nodes. 


3.2. IPv6 Network Operations 


The IPv6 Operations (V60PS) working group develops guidelines for the 
operation of a shared IPv4/IPv6 Internet and provides operational 
guidance on how to deploy IPv6 into existing IPv4-only networks, as 
well as into new network installations. 


o "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213] 
specifies IPv4 compatibility mechanisms for dual-stack and 
configured tunneling that can be implemented by IPv6 hosts and 
routers. "Dual stack" implies providing complete implementations 
of both IPv4 and IPv6, and configured tunneling provides a means 
to carry IPv6 packets over unmodified IPv4 routing 
infrastructures. 


o "Transition Scenarios for 3GPP Networks" [RFC3574] lists different 
scenarios in 3GPP defined packet network that would need IPv6 and 
IPv4 transition, where "Analysis on IPv6 Transition in Third 
Generation Partnership Project (3GPP) Networks" [RFC4215] does a 
more detailed analysis of the transition scenarios that may come 
up in the deployment phase of IPv6 in 3GPP packet networks. 


o "Scenarios and Analysis for Introducing IPv6 into ISP Networks" 
[RFC4029] describes and analyzes different scenarios for the 
introduction of IPv6 into an ISP's existing IPv4 network. "IPv6 
Deployment Scenarios in 802.16 Networks" [RFC5181] provides a 
detailed description of IPv6 deployment, integration methods, and 
scenarios in wireless broadband access networks (802.16) in 
coexistence with deployed IPv4 services. [RFC4057] describes the 
scenarios for IPv6 deployment within enterprise networks. 


o “Application Aspects of IPv6 Transition" [RFC4038] specifies 
scenarios and application aspects of IPv6 transition considering 
how to enable IPv6 support in applications running on IPv6 hosts, 
and giving guidance for the development of IP-version-independent 
applications. 


o  "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] 
updates RFC 5735 and requested the allocation of an IPv4/10 
address block to be used as "Shared Carrier-Grade Network Address 
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Translation (CGN) Space" by Service Providers to number the 
interfaces that connect CGN devices to Customer Premises Equipment 
(CPE). 


.3. Policy-Based Management 


1. IETF Policy Framework 


The IETF specified a general policy framework [RFC2753] for managing, 
sharing, and reusing policies in a vendor-independent, interoperable, 
and scalable manner. [RFC3460] specifies the Policy Core Information 
Model (PCIM) as an object-oriented information model for representing 
policy information. PCIM has been developed jointly in the IETF 
Policy Framework (POLICY) working group and the Common Information 
Model (CIM) activity in the Distributed Management Task Force (DMTF). 
PCIM has been published as extensions to CIM [DMTF-CIM]. 


The IETF Policy Framework is based on a policy-based admission 
control specifying two main architectural elements: the Policy 
Enforcement Point (PEP) and the Policy Decision Point (PDP). For the 
purpose of network management, policies allow an operator to specify 
how the network is to be configured and monitored by using a 
descriptive language. Furthermore, it allows the automation of a 
number of management tasks, according to the requirements set out in 
the policy module. 


The IETF Policy Framework has been accepted by the industry as a 
standard-based policy management approach and has been adopted by 
different SDOs, e.g., for 3GGP charging standards. 


.2. Use of Common Open Policy Service (COPS) for Policy Provisioning 
(COPS-PR) 


[RFC3159] defines the Structure of Policy Provisioning Information 
(SPPI), an extension to the SMIv2 modeling language used to write 
Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the 
Common Open Policy Service (COPS) protocol [RFC2748] for the 
provisioning of policy information. COPS provides a simple client/ 
server model for supporting policy control over QoS signaling 
protocols. The COPS-PR specification is independent of the type of 
policy being provisioned (QoS, security, etc.) but focuses on the 
mechanisms and conventions used to communicate provisioned 
information between policy-decision-points (PDPs) and policy 
enforcement points (PEPs). Policy data is modeled using PIB modules. 


COPS-PR has not been widely deployed, and operators have stated that 
its use of binary encoding for management data makes it difficult to 
develop automated scripts for simple configuration management tasks 
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in most text-based scripting languages. In the IAB Workshop on 
Network Management [RFC3535], the consensus of operators and protocol 
developers indicated a lack of interest in PIB modules for use with 
COPS-PR. 


As a result, even if COPS-PR and the Structure of Policy Provisioning 
Information (SPPI) were initially approved as Proposed Standards, the 
IESG has not approved any PIB modules as Proposed Standard, and the 
use of COPS-PR is not recommended. 


3e As IP Performance Metrics (IPPM) 


The IPPM working group has defined metrics for accurately measuring 
and reporting the quality, performance, and reliability of Internet 
data delivery. The metrics include connectivity, one-way delay and 
loss, round-trip delay and loss, delay variation, loss patterns, 
packet reordering, bulk transport capacity, and link bandwidth 
capacity. 


These metrics are designed for use by network operators and their 
customers, and they provide unbiased quantitative measures of 
performance. The IPPM metrics have been developed inside an active 
measurement context, that is, the devices used to measure the metrics 
produce their own traffic. However, most of the metrics can be used 
inside a passive context as well. At the time of this writing, there 
is no work planned in the area of passive measurement. 


As a property, individual IPPM performance and reliability metrics 
need to be well defined and concrete: thus, implementable. 
Furthermore, the methodology used to implement a metric needs to be 
repeatable with consistent measurements. 


IPPMs have been adopted by different organizations, e.g., the Metro 
Ethernet Forum. 


Note that this document does not aim to cover OAM technologies on the 
data-path and, as such, the discussion of IPPM-based active versus 
passive monitoring as well as the data plane measurement and its 
diagnostics is rather incomplete. For a detailed overview and 
discussion of IETF OAM standards and IPPM measurement mechanisms, the 
reader is referred to the documents listed at the end of Section 1.2 
("Related Work") but especially to [OAM-OVERVIEW]. 
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The following are essential IPPM documents: 


o 


"Framework for IP Performance Metrics" [RFC2330] defines a general 
framework for particular metrics developed by the IPPM working 
group, and it defines the fundamental concepts of 'metric” and 
"measurement methodology’. It also discusses the issue of 
measurement uncertainties and errors as well as introduces the 
notion of empirically defined metrics and how metrics can be 
composed. 


"A One-way Delay Metric for IPPM" [RFC2679] defines a metric for 
the one-way delay of packets across Internet paths. It builds on 
notions introduced in the IPPM Framework document. 


"A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric 
for the round-trip delay of packets across network paths and 
closely follows the corresponding metric for one-way delay. 


"IP Packet Delay Variation Metric for IP Performance Metrics 
(IPPM)" [RFC3393] refers to a metric for variation in the delay of 
packets across network paths and is based on the difference in the 
one-way-delay of selected packets called "IP Packet Delay 
Variation (ipdv)". 


"A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric 
for one-way packet loss across Internet paths. 


"A One-Way Packet Duplication Metric" [RFC5560] defines a metric 
for the case where multiple copies of a packet are received, and 
it discusses methods to summarize the results of streams. 


"Packet Reordering Metrics" [RFC4737] defines metrics to evaluate 
whether a network has maintained packet order on a packet-by- 
packet basis and discusses the measurement issues, including the 
context information required for all metrics. 


"IPPM Metrics for Measuring Connectivity" [RFC2678] defines a 
series of metrics for connectivity between a pair of Internet 
hosts. 


"Framework for Metric Composition" [RFC5835] describes a detailed 
framework for composing and aggregating metrics. 


"Guidelines for Considering New Performance Metric Development" 
[BCP170] describes the framework and process for developing 
Performance Metrics of protocols and applications transported over 
IETF-specified protocols. 
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To measure these metrics, two protocols and a sampling method have 
been standardized: 


o "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures 
unidirectional characteristics such as one-way delay and one-way 
loss between network devices and enables the interoperability of 
these measurements. OWAMP is discussed in more detail in 
[OAM-OVERVIEW] . 


o "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds 
round-trip or two-way measurement capabilities to OWAMP. TWAMP is 
discussed in more detail in [OAM-OVERVIEW]. 


o "Network performance measurement with periodic streams" [RFC3432] 
describes a periodic sampling method and relevant metrics for 
assessing the performance of IP networks, as an alternative to the 
Poisson sampling method described in [RFC2330]. 


For information on MIB modules related to IP Performance Metrics see 
Section 4.2.4. 


3.5. Remote Authentication Dial-In User Service (RADIUS) 


"Remote Authentication Dial In User Service (RADIUS)" [RFC2865] 
describes a client/server protocol for carrying authentication, 
authorization, and configuration information between a Network Access 
Server (NAS), which desires to authenticate its links, and a shared 
authentication server. The companion document "Radius Accounting" 
[RFC2866] describes a protocol for carrying accounting information 
between a NAS and a shared accounting server. [RFC2867] adds 
required new RADIUS accounting attributes and new values designed to 
support the provision of tunneling in dial-up networks. 


The RADIUS protocol is widely used in environments like enterprise 
networks, where a single administrative authority manages the network 
and protects the privacy of user information. RADIUS is deployed in 
the networks of fixed broadband access provider as well as cellular 
broadband operators. 


RADIUS uses attributes to carry the specific authentication, 
authorization, information, and configuration details. RADIUS is 
extensible with a known limitation of a maximum of 255 attribute 
codes and 253 octets as attribute content length. RADIUS has Vendor- 
Specific Attributes (VSAs), which have been used both for vendor- 
specific purposes (as an addition to standardized attributes) as well 
as to extend the limited attribute code space. 
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The RADIUS protocol uses a shared secret along with the MD5 hash 
algorithm to secure passwords [RFC1321]. Based on the known threads, 
additional protection like IPsec tunnels [RFC4301] are used to 
further protect the RADIUS traffic. However, building and 
administering large IPsec-protected networks may become a management 
burden, especially when the IPsec-protected RADIUS infrastructure 
should provide inter-provider connectivity. Moving towards TLS-based 
security solutions [RFC5246] and establishing dynamic trust 
relationships between RADIUS servers has become a trend. Since the 
introduction of TCP transport for RADIUS [RFC6613], it became natural 
to have TLS support for RADIUS. An ongoing work is "Transport Layer 
Security (TLS) encryption for RADIUS" [RFC6614]. 


"RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a 
number of RADIUS attributes designed to support the compulsory 
provision of tunneling in dial-up network access. Some applications 
involve compulsory tunneling, i.e., the tunnel is created without any 
action from the user and without allowing the user any choice in the 
matter. In order to provide this functionality, specific RADIUS 
attributes are needed to carry the tunneling information from the 
RADIUS server to the tunnel end points. "Signalling Connection 
Control Part User Adaptation Layer (SUA)" [RFC3868] defines the 
necessary attributes, attribute values, and the required IANA 
registries. 


"RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over 
IPv6 and the RADIUS attributes used to support the IPv6 network 
access. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes 
how to transport delegated IPv6 prefix information over RADIUS. 


"RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675] 
defines additional attributes for dynamic Virtual LAN assignment and 
prioritization, for use in provisioning of access to IEEE 802 local 
area networks usable with RADIUS and diameter. 


"Common Remote Authentication Dial In User Service (RADIUS) 
Implementation Issues and Suggested Fixes" [RFC5080] describes common 
issues seen in RADIUS implementations and suggests some fixes. Where 
applicable, unclear statements and errors in previous RADIUS 
specifications are clarified. People designing extensions to RADIUS 
protocol for various deployment cases should get familiar with 
"RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known 
interoperability challenges. 


"RADIUS Extension for Digest Authentication" [RFC5090] defines an 
extension to the RADIUS protocol to enable support of Digest 
Authentication, for use with HTTP-style protocols like the Session 
Initiation Protocol (SIP) and HTTP. 
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"Carrying Location Objects in RADIUS and DIAMETER" [RFC5580] 
describes procedures for conveying access-network ownership and 
location information based on civic and geospatial location formats 
in RADIUS and diameter. 


"Remote Authentication Dial-In User Service (RADIUS) Authorization 
for Network Access Server (NAS) Management" [RFC5607] specifies 
required RADIUS attributes and their values for authorizing a 
management access to a NAS. Both local and remote management are 
supported, with access rights and management privileges. Specific 
provisions are made for remote management via Framed Management 
protocols, such as SNMP and NETCONF, and for management access over a 
secure transport protocol. 


"RADIUS (Remote Authentication Dial In User Service) Support For 
Extensible Authentication Protocol (EAP)" [RFC3579] describes how to 
use RADIUS to convey an EAP [RFC3748] payload between the 
authenticator and the EAP server using RADIUS. RFC 3579 is widely 
implemented, for example, in WLAN and 802.1 X environments. "IEEE 
802.1X Remote Authentication Dial In User Service (RADIUS) Usage 
Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X 
authenticators. In the context of 802.1X and EAP-based 
authentication, the VSAs described in [RFC2458] have been widely 
accepted by the industry. "RADIUS Extensions" [RFC2869] is another 
important RFC related to EAP use. RFC 2869 describes additional 
attributes for carrying AAA information between a NAS and a shared 
accounting server using RADIUS. It also defines attributes to 
encapsulate EAP message payload. 


There are different MIB modules defined for multiple purposes to use 
with RADIUS (see Sections 4.2.3 and 4.2.5). 


3.6. Diameter Base Protocol (Diameter) 


Diameter [RFC3588] provides an Authentication, Authorization, and 
Accounting (AAA) framework for applications such as network access or 
IP mobility. Diameter is also intended to work in local AAA and in 
roaming scenarios. Diameter provides an upgrade path for RADIUS but 
is not directly backwards compatible. 


Diameter is designed to resolve a number of known problems with 
RADIUS. Diameter supports server failover, reliable transport over 
TCP and SCTP, well-documented functions for proxy, redirect and relay 
agent functions, server-initiated messages, auditability, and 
capability negotiation. Diameter also provides a larger attribute 
space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS. 
Diameter features make it especially appropriate for environments, 
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where the providers of services are in different administrative 
domains than the maintainer (protector) of confidential user 
information. 


Other notable differences to RADIUS are as follows: 
o Network and Transport Layer Security (IPsec or TLS), 
o Stateful and stateless models, 


o Dynamic discovery of peers (using DNS Service Record (SRV) and 
Naming Authority Pointer (NAPTR)), 


o Concept of an application that describes how a specific set of 
commands and Attribute-Value Pairs (AVPs) are treated by diameter 
nodes. Each application has an IANA-assigned unique identifier, 


o Support of application layer acknowledgements, failover methods 
and state machines, 


o Basic support for user-sessions and accounting, 
o Better roaming support, 

o Error notification, and 

o Easy extensibility. 


The Diameter protocol is designed to be extensible to support, e.g., 
proxies, brokers, mobility and roaming, Network Access Servers 
(NASREQ), and Accounting and Resource Management. Diameter 
applications extend the Diameter base protocol by adding new commands 
and/or attributes. Each application is defined by a unique IANA- 
assigned application identifier and can add new command codes and/or 
new mandatory AVPs. 


The Diameter application identifier space has been divided into 
Standards Track and /First Come First Served’ vendor-specific 
applications. The following are examples of Diameter applications 
published at IETF: 


o Diameter Base Protocol Application [RFC3588]: Required support 
from all Diameter implementations. 


o Diameter Base Accounting Application [RFC3588]: A Diameter 
application using an accounting protocol based on a server- 
directed model with capabilities for real-time delivery of 
accounting information. 


Ersue & Claise Informational [Page 32] 


RFC 6632 IETF Management Standards June 2012 


o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application 
that allows a Diameter server to authenticate, authorize, and 
collect accounting information for Mobile IPv4 services rendered 
to a mobile node. 


o Diameter Network Access Server Application (NASREQ, [RFC4005]): A 
Diameter application used for AAA services in the NAS environment. 


o Diameter Extensible Authentication Protocol Application [RFC4072]: 
A Diameter application that carries EAP packets between a NAS and 
a back-end authentication server. 


o Diameter Credit-Control Application [RFC4006]: A Diameter 
application that can be used to implement real-time credit-control 
for a variety of end-user services such as network access, Session 
Initiation Protocol (SIP) services, messaging services, and 
download services. 


o Diameter Session Initiation Protocol Application [RFC4740]: A 
Diameter application designed to be used in conjunction with SIP 
and provides a Diameter client co-located with a SIP server, with 
the ability to request the authentication of users and 
authorization of SIP resources usage from a Diameter server. 


o Diameter Quality-of-Service Application [RFC5866]: A Diameter 
application allowing network elements to interact with Diameter 
servers when allocating QoS resources in the network. 


o Diameter Mobile IPv6 IKE (MIP61) Application [RFC5778]: A Diameter 
application that enables the interaction between a Mobile IP home 
agent and a Diameter server and is used when the mobile node is 
authenticated and authorized using IKEv2 [RFC5996]. 


o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A 
Diameter application that enables the interaction between a Mobile 
IP home agent and a Diameter server and is used when the mobile 
node is authenticated and authorized using the Mobile IPv6 
Authentication Protocol [RFC4285]. 


The large majority of Diameter applications are vendor-specific and 
mainly used in various SDOs outside the IETF. One example SDO using 
diameter extensively is 3GPP (e.g., 3GPP ’IP Multimedia Subsystem’ 
(IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]). 
Recently, during the standardization of the '3GPP Evolved Packet 
Core’ [3GPPEPC], diameter was chosen as the only AAA signaling 
protocol. 
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One part of diameter's extensibility mechanism is an easy and 
consistent way of creating new commands for the need of applications. 
RFC 3588 proposed to define diameter command code allocations with a 
new RFC. This policy decision caused undesired use and redefinition 
of existing command codes within SDOs. Diverse RFCs have been 
published as simple command code allocations for other SDO purposes 
(see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719] 
changed the command code policy and added a range for vendor-specific 
command codes to be allocated on a 'First Come First Served’ basis by 
IANA. 


The implementation and deployment experience of diameter has led to 
the ongoing development of an update of the base protocol [DIAMETER], 
which introduces TLS as the preferred security mechanism and 
deprecates the in-band security negotiation for TLS. 


Some Diameter protocol enhancements and clarifications that logically 
fit better into [DIAMETER], are also needed on the existing 
deployments based on RFC 3588. Therefore, protocol extensions 
specifically usable in large inter-provider roaming network scenarios 
are made available for RFC 3588. Two currently existing 
specifications are mentioned below: 


o "Clarifications on the Routing of Diameter Requests Based on the 
Username and the Realm" [RFC5729] defines the behavior required 
for Diameter agents to route requests when the User-Name AVP 
contains a NAI formatted with multiple realms. These multi-realm 
Network Access Identifiers are used in order to force the routing 
of request messages through a predefined list of mediating realms. 


o "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) 
Usage" [RFC6408] describes an improved DNS-based dynamic Diameter 
agent discovery mechanism without having to do diameter capability 
exchange beforehand with a number of agents. 


There have been a growing number of Diameter Framework documents from 
the IETF that basically are just a collection of AVPs for a specific 
purpose or a system architecture with semantic AVP descriptions anda 
logic for "imaginary" applications. From a standardization point of 
view, this practice allows the development of larger system 
architecture documents that do not need to reference AVPs or 
application logic outside the IETF. Below are examples of a few 
recent AVP and Framework documents: 
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o “Diameter Mobile IPv6: Support for Network Access Server to 
Diameter Server Interaction" [RFC5447] describes the bootstrapping 
of the Mobile IPv6 framework and the support of interworking with 
existing AAA infrastructures by using the diameter NAS-to-home-AAA 
server interface. 


o "Traffic Classification and Quality of Service (QoS) Attributes 
for Diameter" [RFC5777] defines a number of Diameter AVPs for 
traffic classification with actions for filtering and QoS 
treatment. 


o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local 
Mobility Anchor Interaction with Diameter Server" [RFC5779] 
defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) 
entities (MAG and LMA) and a AAA server within a PMIPv6 Domain. 


For information on MIB modules related to diameter, see 
Section 4.2.5. 


3.7. Control and Provisioning of Wireless Access Points (CAPWAP) 


Wireless LAN (WLAN) product architectures have evolved from single 
autonomous Access Points to systems consisting of a centralized 
Access Controller (AC) and Wireless Termination Points (WIPs). The 
general goal of centralized control architectures is to move access 
control, including user authentication and authorization, mobility 
management, and radio management from the single access point to a 
centralized controller, where an Access Point pulls the information 
from the AC. 


Based on "Architecture Taxonomy for Control and Provisioning of 
Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group 
developed the CAPWAP protocol [RFC5415] to facilitate control, 
management, and provisioning of WIPs specifying the services, 
functions, and resources relating to 802.11 WLAN Termination Points 
in order to allow for interoperable implementations of WTPs and ACs. 
The protocol defines the CAPWAP control plane, including the 
primitives to control data access. The protocol document also 
specifies how configuration management of WIPs can be done and 
defines CAPWAP operations responsible for debugging, gathering 
statistics, logging, and managing firmware as well as discusses 
operational and transport considerations. 


The CAPWAP protocol is prepared to be independent of Layer 2 


technologies, and meets the objectives in "Objectives for Control and 
Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate 
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binding extensions enable the use with additional wireless 
technologies. [RFC5416] defines the CAPWAP Protocol Binding for IEEE 
802.11. 


CAPWAP Control messages, and optionally CAPWAP Data messages, are 
secured using DTLS [RFC6347]. DTLS is used as a tightly integrated, 
secure wrapper for the CAPWAP protocol. 


For information on MIB modules related to CAPWAP, see Section 4.2.2. 
3.8. Access Node Control Protocol (ANCP) 


The Access Node Control Protocol (ANCP) [RFC6320] realizes a control 
plane between a service-oriented Layer 3 edge device, the NAS anda 
Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module 
(DSLAM). As such, ANCP operates in a multi-service reference 
architecture and communicates QoS-, service-, and subscriber-related 
configuration and operation information between a NAS and an AN. 


The main goal of this protocol is to configure and manage access 
equipment and allow them to report information to the NAS in order to 
enable and optimize configuration. 


The framework and requirements for an AN control mechanism and the 
use cases for ANCP are documented in [RFC5851]. 


ANCP offers authentication and authorization between AN and NAS nodes 
and provides replay protection and data-origin authentication. The 
ANCP solution is also robust against Denial-of-Service (DoS) attacks. 
Furthermore, the ANCP solution is recommended to offer 
confidentiality protection. Security Threats and Security 
Requirements for ANCP are discussed in [RFC5713]. 


3.9. Application Configuration Access Protocol (ACAP) 


The Application Configuration Access Protocol (ACAP) [RFC2244] is 
designed to support remote storage and access of program option, 
configuration, and preference information. The datastore model is 
designed to allow a client relatively simple access to interesting 
data, to allow new information to be easily added without server 
reconfiguration, and to promote the use of both standardized data and 
custom or proprietary data. Key features include "inheritance", 
which can be used to manage default values for configuration settings 
and access control lists that allow interesting personal information 
to be shared and group information to be restricted. 
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ACAP's primary purpose is to allow applications access to their 
configuration data from multiple network-connected computers. Users 
can then use any network-connected computer, run any ACAP-enabled 
application, and have access to their own configuration data. To 
enable wide usage client simplicity has been preferred to server or 
protocol simplicity whenever reasonable. 


The ACAP '“authenticate” command uses Simple Authentication and 
Security Layer (SASL) [RFC4422] to provide basic authentication, 
authorization, integrity, and privacy services. All ACAP 
implementations are required to implement the CRAM-MD5 (Challenge- 
Response Authentication Mechanism) [RFC2195] for authentication, 
which can be disabled based on the site security policy. 


3.10. XML Configuration Access Protocol (XCAP) 


The Extensible Markup Language (XML) Configuration Access Protocol 
(XCAP) [RFC4825] has been designed for and is commonly used with SIP- 
based solutions, in particular, for instant messages, presence, and 
SIP conferences. XCAP is a protocol that allows a client to read, 
write, and modify application configuration data stored in XML format 
on a server, where the main functionality is provided by so-called 
"XCAP Application Usages". 


XCAP is a protocol that can be used to manipulate per-user data. 
XCAP is a set of conventions for mapping XML documents and document 
components into HTTP URIs, rules for how the modification of one 
resource affects another, data validation constraints, and 
authorization policies associated with access to those resources. 
Because of this structure, normal HTTP primitives can be used to 
manipulate the data. Like ACAP, XCAP supports the configuration 
needs for a multiplicity of applications. 


All XCAP servers are required to implement HTTP Digest Authentication 
[RFC2617]. Furthermore, XCAP servers are required to implement HTTP 
over TLS (HTTPS) [RFC2818]. It is recommended that administrators 
use an HTTPS URI as the XCAP root URI, so that the digest client 
authentication occurs over TLS. 


The following list summarizes important XCAP application usages: 


o XCAP server capabilities [RFC4825] can be read by clients to 
determine which extensions, application usages, or namespaces a 
server supports. 


o A resource lists application is any application that needs access 
to a list of resources, identified by a URI, to which operations, 
such as subscriptions, can be applied [RFC4826]. 
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4. 


o A Resource List Server (RLS) Services application is a SIP 
application, where a server receives SIP SUBSCRIBE requests for 
resources and generates subscriptions towards the resource list 
[RFC4826]. 


o A Presence Rules application uses authorization policies, also 
known as authorization rules, to specify what presence information 
can be given to which watchers, and when [RFC4827]. 


o A ‘’pidf-manipulation’ application defines how XCAP is used to 
manipulate the contents of PIDF-based presence documents 
[RFC4827]. 


Network Management Data Models 


This section provides two complementary overviews for the network 
management data models standardized at IETF. The first subsection 
focuses on a broader view of models classified into categories such 
as generic and infrastructure data models as well as data models 
matched to different layers. The second subsection is structured 
following the management application view and focuses mainly on the 
data models for the network management tasks fault, configuration, 
accounting, performance, and security management (see [FCAPS]). 


Note that the IETF does not use the FCAPS view as an organizing 
principle for its data models. However, the FCAPS view is used 
widely outside of the IETF for the realization of management tasks 
and applications. Section 4.2 aims to address the FCAPS view to 
enable people outside of the IETF to understand the relevant data 
models in the IETF. 


The different data models covered in this section are MIB modules, 
IPFIX Information Elements, Syslog Structured Data Elements, and YANG 
modules. There are many technology-specific IETF data models, such 
as transmission and protocol MIBs, which are not mentioned in this 
document and can be found at [RFCSEARCH]. 


This section gives an overview of management data models that have 
reached Draft or Proposed Standard status at the IETF. In 
exceptional cases, important Informational RFCs are referenced. The 
advancement process for management data models beyond Proposed 
Standard status, has been defined in [BCP027] with a more pragmatic 
approach and special considerations on data model specification 
interoperability. However, most IETF management data models never 
advanced beyond Proposed Standard. 
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4.1. IETF Network Management Data Models 


The data models defined by the IETF can be broadly classified into 
the following categories depicted in Figure 1. 


=== ASS + ARSS A A A SS e + 

| | | application-layer data models | | network | 

| generic | +------------------------------- + | management | 
infra- | transport-layer data models | infra- 
structure a a Pepe ene NO ag ee ee F structure 

| data | | network-layer data models | | data 

| models | +------------------------------- + | models | 

| | | link-layer data models | | 

HE +e SR SA A A ee + 


Figure 1: Categories of Network Management Data Models 


Each of the categories is briefly described below. Note that the 
classification used here is intended to provide orientation and 
reflects how most data models have been developed in the IETF by the 
various working groups. This classification does not aim to classify 
correctly all data models that have been defined by the IETF so far. 
The network layering model in the middle of Figure 1 follows the 
four-layer model of the Internet as defined in [RFC1021]. 


The network management object identifiers for use with IETF MIB 
modules defined in the IETF can be found under the IANA registry at 
[SMI-NUMBERS]. 


4.1.1. Generic Infrastructure Data Models 


Generic infrastructure data models provide core abstractions that 
many other data models are built upon. The most important example is 
the interfaces data model defined in the IF-MIB [RFC2863]. It 
provides the basic notion of network interfaces and allows expressing 
stacking/layering relationships between interfaces. The interfaces 
data model also provides basic monitoring objects that are widely 
used for performance and fault management. 


The second important infrastructure data model is defined in the 
Entity MIB [RFC4133]. It exports the containment hierarchy of the 
physical entities (slots, modules, ports) that make up a networking 
device and, as such, it is a key data model for inventory management. 
Physical entities can have pointers to other data models that provide 
more specific information about them (e.g., physical ports usually 


point to the related network interface). Entity MIB extensions exist 
for physical sensors such as temperature sensors embedded on line 
cards or sensors that report fan rotation speeds [RFC3433]. The 
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Entity State MIB [RFC4268] models states and alarms of physical 
entities. Some vendors have extended the basic Entity MIB with 
several proprietary data models. 


4.1.2. Link-Layer Data Models 


A number of data models exist in the form of MIB modules covering the 
link layers IP runs over, such as Asymmetric Bit-Rate DSL (ADSL) 
[RFC4706], Very high bit-rate Digital Subscriber Line (VDSL) 
[RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606], 
Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363]. 
These so-called transmission data models typically extend the generic 
network interfaces data model with interface type specific 
information. Most of the link-layer data models focus on monitoring 
capabilities that can be used for performance and fault management 
functions and, to some lesser extent, for accounting and security 
management functions. Meanwhile, the IEEE has taken over the 
responsibility to maintain and further develop data models for the 
IEEE 802 family of protocols [RFC4663]. The cable modem industry 
consortium DOCSIS is working with the IETF to publish data models for 
cable modem networks as IETF Standards Track specifications. 


4.1.3. Network-Layer Data Models 


There are data models in the form of MIB modules covering IP/ICMP 
[RFC4293] [RFC4292] network protocols and their extensions (e.g., 
Mobile IP), the core protocols of the Internet. In addition, there 
are data models covering popular unicast routing protocols (OSPF 
[RFC4750], IS-IS [RFC4444], BGP-4 [RFC4273]) and multicast routing 
protocols (PIM [RFC5060]). 


Detailed models also exist for performance measurements in the form 
of IP Performance Metrics [RFC2330] (see Section 3.4). 


The necessary data model infrastructure for configuration data models 
covering network layers are currently being defined using NETCONF 
[RFC6242] and YANG [RFC6020]. 


4.1.4. Transport-Layer Data Models 
There are data models for the transport protocols TCP [RFC4022], UDP 


[RFC4113], and SCTP [RFC3873]. For TCP, a data model providing 
extended statistics is defined in [RFC4898]. 
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4.1.5. Application-Layer Data Models 


Some data models have been developed for specific application 
protocols (e.g., SIP [RFC4780]). In addition, there are data models 
that provide a generic infrastructure for instrumenting applications 
in order to obtain data useful primarily for performance management 
and fault management [RFC2287] [RFC2564]. In general, however, 
generic application MIB modules have been less successful in gaining 
widespread deployment. 


4.1.6. Network Management Infrastructure Data Models 


A number of data models are concerned with the network management 
system itself. This includes, in addition to a set of SNMP MIB 
modules for monitoring and configuring SNMP itself [RFC3410], some 
MIB modules providing generic functions such as the calculation of 
expressions over MIB objects, generic functions for thresholding and 
event generation, event notification logging functions, and data 
models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877]. 


In addition, there are data models that allow the execution of basic 
reachability and path discovery tests [RFC4560]. Another collection 
of MIB modules provides remote monitoring functions, ranging from the 
data link layer up to the application layer. This is known as the 
"RMON family of MIB modules" [RFC3577]. 


The IPFIX Protocol [RFC5101] (Section 2.3) is used to export 
information about network flows collected at so-called Observation 
Points (typically, a network interface). The IEs [RFC5102] carried 
in IPFIX cover the majority of the network and transport layer header 
fields and a few link-layer-specific fields. Work is underway to 
further extend the standardized information that can be carried in 
IPFIX. 


The Syslog Protocol document [RFC5424] (Section 2.2) defines an 
initial set of Structured Data Elements (SDEs) that relate to content 
time quality, content origin, and meta-information about the message, 
such as language. Proprietary SDEs can be used to supplement the 
IETF-defined SDEs. 


4.2. Network Management Data Models - FCAPS View 


This subsection follows the management application view and aims to 
match the data models to network management tasks for fault, 
configuration, accounting, performance, and security management 
([FCAPS]). As OAM is a general term that refers to a toolset, which 
can be used for fault detection, isolation, and performance 
measurement, aspects of FCAPS in the context of the data path, such 
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as fault and performance management, are also discussed in "An 
Overview of Operations, Administration, and Maintenance (OAM) 
Mechanisms" [OAM-OVERVIEW]. 


Some of the data models do not fit into one single FCAPS category per 
design but span multiple areas. For example, there are many 
technology-specific IETF data models, such as transmission and 
protocol MIBs, which cover multiple FCAPS categories, and therefore 
are not mentioned in this subsection and can be found at [RFCSEARCH]. 


4.2.1. Fault Management 


Fault management encloses a set of functions to detect, isolate, 
notify, and correct faults encountered in a network as well as to 
maintain and examine error logs. The data models below can be 
utilized to realize a fault management application. 


[RFC3418], part of SNMPv3 standard [STD62], is a MIB module 
containing objects in the system group that are often polled to 
determine if a device is still operating, and sysUpTime can be used 
to detect if the network management portion of the system has 
restarted and counters have been re-initialized. 


[RFC3413], part of SNMPv3 standard [STD62], is a MIB module including 
objects designed for managing notifications, including tables for 
addressing, retry parameters, security, lists of targets for 
notifications, and user customization filters. 


The Interfaces Group MIB [RFC2863] builds on the old standard for MIB 
II [STD17] and is used as a primary MIB module for managing and 
monitoring the status of network interfaces. The Interfaces Group 
MIB defines a generic set of managed objects for network interfaces, 
and it provides the infrastructure for additional managed objects 
specific to particular types of network interfaces, such as Ethernet. 


[RFC4560] defines a MIB module for performing ping, traceroute, and 
lookup operations at a host. For troubleshooting purposes, it is 
useful to be able to initiate and retrieve the results of ping or 
traceroute operations when they are performed at a remote host. 


The RMON (Remote Network Monitoring) MIB [STD59] can be configured to 
recognize conditions on existing MIB variables (most notably error 
conditions) and continuously check for them. When one of these 
conditions occurs, the event may be logged, and management stations 
may be notified in a number of ways (for further discussion on RMON, 
see Section 4.2.4). 
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DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] 
provide a superset of the capabilities of the RMON alarm and event 
groups. These modules provide mechanisms for thresholding and 
reporting anomalous events to management applications. 


The Alarm MIB in [RFC3877] and the Alarm Reporting Control MIB in 
[RFC3878] specify mechanisms for expressing state transition models 
for persistent problem states. Alarm MIB defines the following: 


o a mechanism for expressing state transition models for persistent 
problem states, 


o a mechanism to correlate a notification with subsequent state 
transition notifications about the same entity/object, and 


o a generic alarm reporting mechanism (extends ITU-T work on X.733 
[ITU-X733]). 


In particular, [RFC3878] defines objects for controlling the 
reporting of alarm conditions and extends ITU-T work on M.3100 
Amendment 3 [ITU-M3100]. 


Other MIB modules that may be applied to fault management with SNMP 
include: 


o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for 
logging SNMP Notifications. 


o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB 
to provide information about the state of physical entities. 


o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for 
extending the Entity MIB to provide generalized access to 
information related to physical sensors, which are often found in 
networking equipment (such as chassis temperature, fan RPM, power 
supply voltage). 


The Syslog protocol document [RFC5424] defines an initial set of SDEs 
that relate to content time quality, content origin, and meta- 
information about the message, such as language. Proprietary SDEs 
can be used to supplement the IETF-defined SDEs. 


The IETF has standardized MIB Textual-Conventions for facility and 
severity labels and codes to encourage consistency between syslog and 
MIB representations of these event properties [RFC5427]. The intent 
is that these textual conventions will be imported and used in MIB 
modules that would otherwise define their own representations. 
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An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX 
Meters, Exporters, and Collectors (see Section 2.3). The ongoing 
work on the PSAMP MIB module extends the IPFIX MIB modules by managed 
objects for monitoring PSAMP implementations [PSAMP-MIB]. 


The NETCONF working group defined the data model necessary to monitor 
the NETCONF protocol [RFC6022] with the modeling language YANG. The 
monitoring data model includes information about NETCONF datastores, 
sessions, locks, and statistics, which facilitate the management of a 
NETCONF server. The NETCONF monitoring document also defines methods 
for NETCONF clients to discover the data models supported by a 
NETCONF server and defines the operation <get-schema> to retrieve 
them. 


4.2.2. Configuration Management 


Configuration management focuses on establishing and maintaining 
consistency of a system and defines the functionality to configure 
its functional and physical attributes as well as operational 
information throughout its life. Configuration management includes 
configuration of network devices, inventory management, and software 
management. The data models below can be used to utilize 
configuration management. 


MIB modules for monitoring of network configuration (e.g., for 
physical and logical network topologies) already exist and provide 
some of the desired capabilities. New MIB modules might be developed 
for the target functionality to allow operators to monitor and modify 
the operational parameters, such as timer granularity, event 
reporting thresholds, target addresses, etc. 


[RFC3418], part of [STD62], contains objects in the system group 
useful, e.g., for identifying the type of device and the location of 
the device, the person responsible for the device. The SNMPv3 
standard [STD62] furthermore includes objects designed for 
configuring principals, access control rules, notification 
destinations, and for configuring proxy-forwarding SNMP agents, which 
can be used to forward messages through firewalls and NAT devices. 


The Entity MIB [RFC4133] supports mainly inventory management and is 
used for managing multiple logical and physical entities matched to a 
single SNMP agent. This module provides a useful mechanism for 
identifying the entities comprising a system and defines event 
notifications for configuration changes that may be useful to 
management applications. 


[RFC3165] defines a set of managed objects that enable the delegation 
of management scripts to distributed managers. 
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For configuring IPFIX and PSAMP devices, the IPFIX working group 
developed the IPFIX Configuration Data Model [CONF-MODEL], by using 
the YANG modeling language and in close collaboration with the NETMOD 
working group (see Section 2.4.2). The model specifies the necessary 
data for configuring and monitoring Selection Processes, Caches, 
Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- 
compliant monitoring devices. 


At the time of this writing, the NETMOD working group is developing 
core system and interface models in YANG. 


The CAPWAP protocol exchanges message elements using the Type-Length- 
Value (TLV) format. The base TLVs are specified in [RFC5415], while 
the TLVs for IEEE 802.11 are specified in [RFC5416]. The CAPWAP Base 
MIB [RFC5833] specifies managed objects for the modeling the CAPWAP 
protocol and provides configuration and WIP status-monitoring aspects 
of CAPWAP, where the CAPWAP Binding MIB [RFC5834] defines managed 
objects for the modeling of the CAPWAP protocol for IEEE 802.11 
wireless binding. 

Note: RFC 5833 and RFC 5834 have been published as Informational RFCs 
to provide the basis for future work on a SNMP management of the 
CAPWAP protocol. 


4.2.3. Accounting Management 


Accounting management collects usage information of network 
resources. Note that the IETF does not define any mechanisms related 
to billing and charging. Many technology-specific MIBs (link layer, 
network layer, transport layer, or application layer) contain 
counters but are not primarily targeted for accounting and, 
therefore, are not included in this section. 


"RADIUS Accounting Client MIB for IPv6" [RFC4670] defines RADIUS 
Accounting Client MIB objects that support version-neutral IP 
addressing formats. 


"RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS 
Accounting Server MIB objects that support version-neutral IP 
addressing formats. 


IPFIX/PSAMP Information Elements: 


As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines 
components involved in IP flow measurement and reporting of 
information on IP flows. As such, IPFIX records provide fine-grained 
measurement data for flexible and detailed usage reporting and enable 
usage-based accounting. 
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The IPFIX Information Elements (IEs) have been initially defined in 
the IPFIX Information Model [RFC5102] and registered with IANA 
[IANA-IPFIX]. The IPFIX IEs are composed of two types: 


o IEs related to identification of IP flows such as header 
information, derived packet properties, IGP and BGP next-hop IP 
address, BGP AS, etc., and 


o IEs related to counter and timestamps, such as per-flow counters 
(e.g., octet count, packet count), flow start times, flow end 
times, and flow duration, etc. 


The Information Elements specified in the IPFIX Information Model 
[RFC5102] are used by the PSAMP protocol where applicable. PSAMP 
Parameters defined in the PSAMP protocol specification are registered 
at [IANA-PSAMP]. An additional set of PSAMP Information Elements for 
reporting packet information with the IPFIX/PSAMP protocol such as 
Sampling-related IEs are specified in the PSAMP Information Model 
[RFC5477]. These IEs fulfill the requirements on reporting of 
different sampling and filtering techniques specified in [RFC5475]. 


4.2.4. Performance Management 


Performance management covers a set of functions that evaluate and 
report the performance of network elements and the network, with the 
goal to maintain the overall network performance at a defined level. 
Performance management functionality includes monitoring and 
measurement of network performance parameters, gathering statistical 
information, maintaining and examining activity logs. The data 
models below can be used for performance management tasks. 


The RMON (Remote Network Monitoring) MIB [STD59] defines objects for 
collecting data related to network performance and traffic from 
remote monitoring devices. An organization may employ many remote 
monitoring probes, one per network segment, to monitor its network. 
These devices may be used by a network service provider to access a 
(distant) client network. Most of the objects in the RMON MIB module 
are suitable for the monitoring of any type of network, while some of 
them are specific to the monitoring of Ethernet networks. 


RMON allows a probe to be configured to perform diagnostics and to 
collect network statistics continuously, even when communication with 
the management station may not be possible or efficient. The alarm 
group periodically takes statistical samples from variables in the 
probe and compares them to previously configured thresholds. If the 
monitored variable crosses a threshold, an event is generated. 
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"Introduction to the Remote Monitoring (RMON) Family of MIB Modules" 
[RFC3577] describes the documents associated with the RMON Framework 
and how they relate to each other. 


The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up 
to the application layer and defines performance data to monitor. 
The SMON MIB [RFC2613] extends RMON by providing RMON analysis for 
switched networks. 


"Remote Monitoring MIB Extensions for High Capacity Alarms" [RFC3434] 
describes managed objects for extending the alarm thresholding 
capabilities found in the RMON MIB and provides similar threshold 
monitoring of objects based on the Counter64 data type. 


"Remote Network Monitoring Management Information Base for High 
Capacity Networks" [RFC3273] defines objects for managing RMON 
devices for use on high-speed networks. 


"Remote Monitoring MIB Extensions for Interface Parameters 
Monitoring" [RFC3144] describes an extension to the RMON MIB with a 
method of sorting the interfaces of a monitored device according to 
values of parameters specific to this interface. 


[RFC4710] describes Real-Time Application Quality of Service 
Monitoring (RAQMON), which is part of the RMON protocol family. 
RAQMON supports end-to-end QoS monitoring for multiple concurrent 
applications and does not relate to a specific application transport. 
RAQMON is scalable and works well with encrypted payload and 
Signaling. RAQMON uses TCP to transport RAQMON PDUs. 


[RFC4711] proposes an extension to the Remote Monitoring MIB [STD59] 
and describes managed objects used for RAQMON. [RFC4712] specifies 
two transport mappings for the RAQMON information model using TCP as 
a native transport and SNMP to carry the RAQMON information from a 
RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). 


"Application Performance Measurement MIB" [RFC3729] uses the 
architecture created in the RMON MIB and defines objects by providing 
measurement and analysis of the application performance as 
experienced by end-users. [RFC3729] enables the measurement of the 
quality of service delivered to end-users by applications. 


"Transport Performance Metrics MIB" [RFC4150] describes managed 
objects used for monitoring selectable Performance Metrics and 
statistics derived from the monitoring of network packets and sub- 
application level transactions. The metrics can be defined through 
reference to existing IETF, ITU, and other SDOs’ documents. 
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The IPPM working group has defined "IP Performance Metrics (IPPM) 
Metrics Registry" [RFC4148]. Note that with the publication of 
[RFC6248], [RFC4148] and the corresponding IANA registry for IPPM 
metrics have been declared Obsolete and shouldn't be used. 


The IPPM working group defined the "Information Model and XML Data 
Model for Traceroute Measurements" [RFC5388], which defines a common 
information model dividing the IEs into two semantically separated 
groups (configuration elements and results elements) with an 
additional element to relate configuration elements and results 
elements by means of a common unique identifier. Based on the 
information model, an XML data model is provided to store the results 
of traceroute measurements. 


"Session Initiation Protocol Event Package for Voice Quality 
Reporting" [RFC6035] defines a SIP event package that enables the 
collection and reporting of metrics that measure the quality for 
Voice over Internet Protocol (VoIP) sessions. 


4.2.5. Security Management 


Security management provides the set of functions to protect the 
network and system from unauthorized access and includes functions 
such as creating, deleting, and controlling security services and 
mechanisms, key management, reporting security-relevant events, and 
authorizing user access and privileges. Based on their support for 
authentication and authorization, RADIUS and diameter are seen as 
security management protocols. The data models below can be used to 
utilize security management. 


[RFC3414], part of [STD62], specifies the procedures for providing 
SNMPv3 message-level security and includes a MIB module for remotely 
monitoring and managing the configuration parameters for the USM. 


[RFC3415], part of [STD62], describes the procedures for controlling 
access to management information in the SNMPv3 architecture and 
includes a MIB module, which defines managed objects to access 
portions of an SNMP engine’s Local Configuration Datastore (LCD). As 
such, this MIB module enables remote management of the configuration 
parameters of the VACM. 


The NETCONF Access Control Model (NACM) [RFC6536] addresses the need 
for access control mechanisms for the operation and content layers of 
NETCONF, as defined in [RFC6241]. As such, the NACM proposes 
standard mechanisms to restrict NETCONF protocol access for 
particular users to a pre-configured subset of all available NETCONF 
protocol operations and content within a particular server. 
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There are numerous MIB modules defined for multiple purposes to use 
with RADIUS: 


o “RADIUS Authentication Client MIB for IPv6" [RFC4668] defines 
RADIUS Authentication Client MIB objects that support version- 
neutral IP addressing formats and defines a set of extensions for 
RADIUS authentication client functions. 


o “RADIUS Authentication Server MIB for IPv6" [RFC4669] defines 
RADIUS Authentication Server MIB objects that support version- 
neutral IP addressing formats and defines a set of extensions for 
RADIUS authentication server functions. 


o “RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the 
MIB module for entities implementing the client side of the 
Dynamic Authorization Extensions to RADIUS [RFC5176]. 


o "RADIUS Dynamic Authorization Server MIB" [RFC4673] defines the 
MIB module for entities implementing the server side of the 
Dynamic Authorization Extensions to RADIUS [RFC5176]. 


The MIB Module definitions in [RFC4668], [RFC4669], [RFC4672], 
[RFC4673] are intended to be used only for RADIUS over UDP and do not 
support RADIUS over TCP. There is also a recommendation that RADIUS 
clients and servers implementing RADIUS over TCP should not reuse 
earlier listed MIB modules to perform statistics counting for RADIUS- 
over-TCP connections. 


Currently, there are no standardized MIB modules for diameter 
applications, which can be considered as a lack on the management 
side of diameter nodes. 


5. Security Considerations 


This document gives an overview of IETF network management standards 
and summarizes existing and ongoing development of IETF Standards 
Track network management protocols and data models. As such, it does 
not have any security implications in or of itself. 


For each specific technology discussed in the document a summary of 
its security usage has been given in corresponding chapters. Ina 
few cases, e.g., for SNMP, a detailed description of developed 
security mechanisms has been provided. 


The attention of the reader is particularly drawn to the security 
discussion in following document sections: 


o SNMP Security and Access Control Models in Section 2.1.4.1, 
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o 


User-based Security Model (USM) in Section 2.1.4.2, 
View-based Access Control Model (VACM) in Section 2.1.4.3, 
SNMP Transport Security Model in Section 2.1.5.1, 

Secure syslog message delivery in Section 2.2, 


Use of secure NETCONF message transport and the NETCONF Access 
Control Model (NACM) in Section 2.4.1, 


Message authentication for Dynamic Host Configuration Protocol 
(DHCP) in Section 3.1.1, 


Security for Remote Authentication Dial-In User Service (RADIUS) 
in conjunction with EAP and IEEE 802.1X authenticators in 


Section 3.5, 


Built-in and transport security for the Diameter Base Protocol in 
Section 3.6, 


Transport security for Control And Provisioning of Wireless Access 
Points (CAPWAP) in Section 3.7, 


Built-in security for Access Node Control Protocol (ANCP) in 
Section 3.8, 


Security for Application Configuration Access Protocol (ACAP) in 
Section 3.09, 


Security for XML Configuration Access Protocol (XCAP) in 
Section 3.10, and 


Data models for Security Management in Section 4.2.5. 


The authors would also like to refer to detailed security 
consideration sections for specific management standards described in 
this document, which contain comprehensive discussion of security 
implications of the particular management protocols and mechanisms. 
Among others, security consideration sections of following documents 
should be carefully read before implementing the technology. 


o 


For SNMP security in general, subsequent security consideration 
sections in [STD62], which includes RFCs 3411-3418, 


Security considerations section in Section 8 of [BCP074] for the 
coexistence of SNMP versions 1, 2, and 3, 
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TLS Transport Model for SNMP in 
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NETCONF Access Control Model 
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CAPWAP protocol in Section 12 of 


ANCP protocol in Section 11 of 


XCAP protocol in Section 14 of 


o Security considerations for the 
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Appendix A. High-Level Classification of Management Protocols and Data 
Models 


The following subsections aim to guide the reader for the fast 
selection of the management standard in interest and can be used as a 
dispatcher to forward to the appropriate chapter. The subsections 
below classify the protocols on one hand according to high-level 
criteria such as push versus pull mechanism, and passive versus 
active monitoring. On the other hand, the protocols are categorized 
concerning the network management task they address or the data model 
extensibility they provide. Based on the reader’s requirements, a 
reduced set of standard protocols and associated data models can be 
selected for further reading. 


As an example, someone outside of IETF typically would look for the 
TWAMP protocol in the Operations and Management Area working groups 
as it addresses performance management. However, the protocol TWAMP 
has been developed by the IPPM working group in the Transport Area. 


Note that not all protocols have been listed in all classification 
sections. Some of the protocols, especially the protocols with 
specific focus in Section 3 cannot be clearly classified. Note also 
that COPS and COPS-PR are not listed in the tables, as COPS-PR is not 
recommended to use (see Section 3.3). 


A.1. Protocols Classified by Standards Maturity in the IETF 


This section classifies the management protocols according their 
standard maturity in the IETF. The IETF standard maturity levels 
Proposed, Draft, or Internet Standard, are defined in [RFC2026] (as 
amended by [RFC6410]). An Internet Standard is characterized by a 
high degree of technical maturity and by a generally held belief that 
the specified protocol or service provides significant benefit to the 
Internet community. 


The table below covers the standard maturity of the different 
protocols listed in this document. Note that only the main protocols 
(and not their extensions) are noted. An RFC search tool listing the 
current document status is available at [RFCSEARCH]. 
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SNMP [STD62] [REC3411] (Section 2.1) 


ACAP [RFC2244] (Section 3.09) 
XCAP [RFC4825] (Section 3.10) 
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Table 1: 
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Syslog [RFC5424] (Section 2.2) 


IPFIX [RFC5101] (Section 2.3) 


PSAMP [RFC5476] (Section 2.3) 


NETCONF [RFC6241] (Section 2.4.1) 


DHCP for IPv4 [RFC2131] (Section 3.1.1) 


DHCP for IPv6 [RFC3315] (Section 3.1.1) 


OWAMP [RFC4656] (Section 3.4) 


TWAMP [RFC5357] (Section 3.4) 


RADIUS [RFC2865] (Section 3.5) 


Diameter [RFC3588] (Section 3.6) 


CAPWAP [RFC5416] (Section 3.7) 


ANCP [RFC6320] (Section 3.8) 


Ad hoc network configuration [RFC5889] 
(Section 3.1.2) 
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A.2. Protocols Matched to Management Tasks 


This subsection classifies the management protocols matching to the 
management tasks for fault, configuration, accounting, performance, 
and security management. 


do $ $2 $2 Ho + 
| Fault Mgmt | Config | Accounting | Performance | Security | 
| | Mgmt | Mgmt | Mgmt | Mgmt 

$ $ $ $ $ == + 
| SNMP | SNMP | SNMP | SNMP | | 
| notif | config. | monitoring | monitoring | | 
| with trap | with set | with get | with get | | 
| operation | operation | operation | operation | | 
Ss LP iS Deel? (ds Bedi ls Bois | | 
| IPFIX | CAPWAP | IPFIX | IPFIX | | 
| (S. 2:3) | (S. 3.7) | (S. 2.3) | (S. 2.3) | | 
| PSAMP | NETCONF | PSAMP | PSAMP | | 
| (S. 2.3) | (S. 2.4.1) | (S. 2.3) | (S. 2.3) | | 
| Syslog | ANCP | RADIUS | | RADIUS | 
| (S. 2.2) | (S. 3.8) | Accounting | | Authent.& | 
| | | ($35) | | Authoriz. | 
| | | | | (s. 3.5) | 
| | | | | | 

AUTOCONF Diameter Diameter 

| | (S. 3.1.2) | Accounting | | Authent. & | 
| | | (S. 3.6) | | Authoriz. | 
| | | | | (S. 3.6) | 
| | ACAP | | | | 
| | (S. 3.9) | | | | 
| | XCAP | | | | 
ews p 
| | DHCP | | | | 
| | (S. 3.1.1) | | | | 
$ +------------ +-------------— $2 $ == + 


Table 2: Protocols Matched to Management Tasks 


Note: Corresponding section numbers are given in parentheses. 
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A.3. Push versus Pull Mechanism 


A pull mechanism is characterized by the Network Management System 
(NMS) pulling the management information out of network elements, 
when needed. A push mechanism is characterized by the network 
elements pushing the management information to the NMS, either when 
the information is available or on a regular basis. 


Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not 
listed in Table 3. 


+--------------------------------- +--------------------------------- + 
| Protocols supporting the Pull | Protocols supporting the Push | 
| mechanism | mechanism | 
+--------------------------------- +--------------------------------- + 
SNMP (except notifications) SNMP notifications 
(Section 2.1) (Section 2.1) 
| NETCONF (except notifications) | NETCONF notifications | 
| (Section 2.4.1) | (Section 2.4.1) | 
| CAPWAP (Section 3.7) | Syslog (Section 2.2) 
| | IPFIX (Section 2.3) | 
| PSAMP (Section 2.3) | 
| RADIUS accounting 
| | (Section 3.5) | 
| | Diameter accounting | 
| | (Section 3.6) | 
FO +--------------------------------- + 
Table 3: Protocol Classification by Push versus Pull Mechanism 
A.4. Passive versus Active Monitoring 


Monitoring can be divided into two categories: passive and active 
monitoring. Passive monitoring can perform the network traffic 
monitoring, monitoring of a device, or the accounting of network 
resource consumption by users. Active monitoring, as used in this 
document, focuses mainly on active network monitoring and relies on 
the injection of specific traffic (also called "synthetic traffic"), 
which is then monitored. The monitoring focus is indicated in the 
table below as "network", "device", or "accounting". 


This classification excludes non-monitoring protocols, such as 
configuration protocols: Ad hoc network autoconfiguration, ANCP, and 
XCAP. Note that some of the active monitoring protocols, in the 
context of the data path, e.g., ICMP Ping and Traceroute [RFC1470], 
Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual 
Circuit Connectivity Verification (VCCV) [RFC5085] are covered in 
[OAM-OVERVIEW] . 
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| Protocols supporting passive 
| monitoring 


Protocols supporting active 
monitoring 


OWAMP (network) (Section 3.4) 
TWAMP (network) (Section 3.4) 


| IPFIX (network) (Section 2.3) 
| PSAMP (network) (Section 2.3) 
| SNMP (network and device) 
| (Section 2.1) 

NETCONF (device) 

(Section 2.4.1) 
| RADIUS (accounting) | 
| (Section 3.5) | 
| Diameter (accounting) | 
| (Section 3.6) | 

+ 
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| 
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| 
| 
| 
l 
| 
| 
| 
| 
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CAPWAP (device) (Section 3.7) 


Table 4: Protocols for Passive and Active Monitoring and Their 
Monitoring Focus 


The application of SNMP to passive traffic monitoring (e.g., with 
RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB 
modules used. However, the SNMP protocol itself does not have 
operations, which support active monitoring. NETCONF can be used 
passive monitoring, e.g., with the NETCONF Monitoring YANG module 
[RFC6022] for the monitoring of the NETCONF protocol. CAPWAP 
monitors the status of a Wireless Termination Point. 


RADIUS and diameter are considered passive monitoring protocols as 


--+ 


for 


they perform accounting, i.e., counting the number of packets/bytes 


for a specific user. 
Supported Data Model Types and Their Extensibility 


The following table matches the protocols to the associated data 
model types. Furthermore, the table indicates how the data model 
be extended based on the available content today and whether the 
protocol contains a built-in mechanism for proprietary extensions 
the data model. 
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PSAMP 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| (S. 2.3) 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


NETCONF 


(S. 2.4.1) 


IPPM OWAMP / 
TWAMP 


(S. 3.4) 
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Data Modeling | 


MIB modules 
defined with 
SMI 
(S. 2.1.3) 
Structured 
Data Elements 
(SDEs) 

(S. 4.2.1) 


IPFIX 
Information 
Elements, 
IPFIX IANA 
registry at 
[IANA-IPFIX] 
(S. 2.3) 


Information 
Elements, as 
an extension 
to IPFIX 
[IANA-IPFIX], 
and PSAMP 
IANA registry 
at 

[ IANA-PSAMP ] 
(S. 2.3) 
YANG modules 


(S. 2.4.2) 


IPPM metrics 


(*) (S. 3.4) 


+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
PSAMP 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Data Model 
Extensions 


New MIB modules 
specified in new 
RFCs 


With the 
procedure to add 
Structured Data 
ID in [RFC5424] 


With the 
procedure to 
Information 
Elements 
specified in 
[RFC5102] 


add 


With the 
procedure to 
Information 
Elements 
specified in 
[RFC5102] 


add 


New YANG modules 
specified in new 
RFCs following 
the guideline in 
[RFC6087] 


New IPPM metrics 
(S. 3.4) 


Informational 


4+------------------ + 


June 2012 


Proprietary Data | 


Modeling 
Extensions 


Enterprise- 
specific MIB 
modules 


Enterprise- 
specific SDEs 


Enterprise- 
specific 
Information 
Elements 
[REC5101] 


Enterprise- 
specific 
Information 
Elements 
[RFC5101] 


Enterprise- 
specific YANG 
modules 


Not applicable 
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| | | | | 
| RADIUS | TLVs | RADIUS-related | Vendor-Specific | 
(S. 339) registries at Attributes 

[IANA-AAA] and [RFC2865] 

| | | [IANA-PROT] | | 

| | | | | 

| Diameter | AVPs | Diameter-related | Vendor-Specific | 

| (S. 3.6) | | registry at | Attributes | 

| | | [IANA-AAA] | [RFC2865] 

| CAPWAP | TLVs | New bindings | Vendor-specific | 

| (S. 3.7) | | specified in new | TLVs 

| | | RFCs | | 

+------------- +--------------- $ o $ o-- + 


Table 5: Data Models and Their Extensibility 


(*): With the publication of [RFC6248], the latest IANA registry for 
IPFIX metrics has been declared Obsolete. 


Appendix B. New Work Related to IETF Management Standards 
B.1. Energy Management (EMAN) 


Energy management is becoming an additional requirement for network 
management systems due to several factors including the rising and 
fluctuating energy costs, the increased awareness of the ecological 
impact of operating networks and devices, and government regulation 
on energy consumption and production. 


The basic objective of energy management is operating communication 
networks and other equipment with a minimal amount of energy while 
still providing sufficient performance to meet service-level 
objectives. Today, most networking and network-attached devices 
neither monitor nor allow controlled energy usage as they are mainly 
instrumented for functions such as fault, configuration, accounting, 
performance, and security management. These devices are not 
instrumented to be aware of energy consumption. There are very few 
means specified in IETF documents for energy management, which 
includes the areas of power monitoring, energy monitoring, and power 
state control. 


A particular difference between energy management and other 
management tasks is that in some cases energy consumption of a device 
is not measured at the device itself but reported by a different 
place. For example, at a Power over Ethernet (PoE) sourcing device 
or at a smart power strip, where one device is effectively metering 
another remote device. This requires a clear definition of the 
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relationship between the reporting devices and identification of 
remote devices for which monitoring information is provided. Similar 
considerations will apply to power state control of remote devices, 
for example, at a PoE sourcing device that switches on and off power 
at its ports. Another example scenario for energy management is a 
gateway to low resourced and lossy network devices in wireless a 
building network. Here the energy management system talks directly 
to the gateway but not necessarily to other devices in the building 
network. 


At the time of this writing, the EMAN working group is working on the 
management of energy-aware devices, covered by the following items: 


o The requirements for energy management, specifying energy 
management properties that will allow networks and devices to 
become energy aware. In addition to energy awareness 
requirements, the need for control functions will be discussed. 
Specifically, the need to monitor and control properties of 
devices that are remote to the reporting device should be 
discussed. 


o The energy management framework, which will describe extensions to 
the current management framework, required for energy management. 
This includes: power and energy monitoring, power states, power 
state control, and potential power state transitions. The 
framework will focus on energy management for IP-based network 
equipment (routers, switches, PCs, IP cameras, phones and the 
like). Particularly, the relationships between reporting devices, 
remote devices, and monitoring probes (such as might be used in 
low-power and lossy networks) need to be elaborated. For the case 
of a device reporting on behalf of other devices and controlling 
those devices, the framework will address the issues of discovery 
and identification of remote devices. 


o The Energy-aware Networks and Devices MIB document, for monitoring 
energy-aware networks and devices, will address devices 
identification, context information, and potential relationship 
between reporting devices, remote devices, and monitoring probes. 


o The Power and Energy Monitoring MIB document will document 
defining managed objects for the monitoring of power states and 
energy consumption/production. The monitoring of power states 
includes the following: retrieving power states, properties of 
power states, current power state, power state transitions, and 
power state statistics. The managed objects will provide means of 
reporting detailed properties of the actual energy rate (power) 
and of accumulated energy. Further, they will provide information 
on electrical power quality. 
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o The Battery MIB document will define managed objects for battery 
monitoring, which will provide means of reporting detailed 
properties of the actual charge, age, and state of a battery and 
of battery statistics. 


o The applicability statement will describe the variety of 
applications that can use the energy framework and associated MIB 
modules. Potential examples are building networks, home energy 
gateway, etc. Finally, the document will also discuss 
relationships of the framework to other architectures and 
frameworks (such as Smart Grid). The applicability statement will 
explain the relationship between the work in this WG and other 
existing standards, e.g., from the IEC, ANSI, DMTF, etc. Note 
that the EMAN WG will be looking into existing standards such as 
those from the IEC, ANSI, DMTF and others, and reuse existing work 
as much as possible. 


The documents of the EMAN working group can be found at [EMAN-WG]. 
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